QUrl::toLocalFile returns a path with an unexpected leading slash

[JonB]

@jsulm
Awaiting answer from OP to:

Are you saying this is the result on both OSes? Linux should handle C:/... differently from Windows?

[J.Hilk]

@JonB said in QUrl::toLocalFile returns a path with an unexpected leading slash:

Linux should handle C:/... differently from Windows

why should it, contrary to Windows, : is not a "forbidden" path character. C: is just a silly folder name, but it should add a /, if its missing

[JonB]

@J-Hilk said in QUrl::toLocalFile returns a path with an unexpected leading slash:

why should it

? Because under Windows C:/... is an absolute path while under Linux it's a relative path, that is why they "differ" in interpretation, so I would expect a difference in behaviour, wouldn't you?

[J.Hilk]

so I did some digging, QURL is actually explicitly handling cases with : in it:

// magic for drives on windows
    if (deslashified.length() > 1 && deslashified.at(1) == QLatin1Char(':') && deslashified.at(0) != QLatin1Char('/')) {
        deslashified.prepend(QLatin1Char('/'));
    } else if (deslashified.startsWith(QLatin1String("//"))) {
        // magic for shared drive on windows
        int indexOfPath = deslashified.indexOf(QLatin1Char('/'), 2);
        url.setHost(deslashified.mid(2, indexOfPath - 2));
        if (indexOfPath > 2)
            deslashified = deslashified.right(deslashified.length() - indexOfPath);
        else
            deslashified.clear();
    }

[JonB]

@J-Hilk said in QUrl::toLocalFile returns a path with an unexpected leading slash:

// magic for drives on windows
deslashified.at(1) == QLatin1Char(':')

Is this in Windows-only code or in code shared with Linux?

I still wish we knew whether the OP is reporting this behaviour on Windows, on Linux, or non both, for clarity.

[J.Hilk]

@JonB shared

[JonB]

@J-Hilk
LOL, then it looks like it isn't treating : as it ought to be under Linux.... Don't try it with Linux relative pathnames starting with <something>:... because it does not look like it handles them correctly, rather it makes an assumption that it is somehow dealing with a pathname which emanates from Windows. I wonder whether it mentions this anywhere, as really this is "naughty" :)

[lguyot]

@JonB Thanks for your interest and your time.

I apologize for the lack of clarity regarding the different OSes under scrutiny.

The output is the same on both OSes, i.e., Ubuntu and Windows.
But I am only concerned by what happens on Windows. This is the real use-case I am interested in.

For Ubuntu, I am ready to accept that the output is correct (and I am not entirely sure of what the correct output should be).

[JonB]

@lguyot
OK then, let's just forget about the Linux case because it just sidelines the issue.

@kkoehne reports:

qDebug() << QUrl::fromLocalFile("C:/images/DJI_0069.JPG").toLocalFile();
"C:/images/DJI_0069.JPG"

under " both Qt 5.15 and Qt 6.3" (and I am guessing he means under Windows anyway?). You are reporting different on just this under your version and Windows (which I don't have)?

[J.Hilk]

@JonB said in QUrl::toLocalFile returns a path with an unexpected leading slash:

under " both Qt 5.15 and Qt 6.3" (and I am guessing he means under Windows anyway?). You are reporting different on just this under your version and Windows (which I don't have)?

I can't confirm that, 5.15.10 results in:
"/C:/images/DJI_0069.JPG" - macOS
C:/images/DJI_0069.JPG- Windows

[mpergand]

@J-Hilk said in QUrl::toLocalFile returns a path with an unexpected leading slash:

"/C:/images/DJI_0069.JPG" - macOS

/c: is non sense on mac
internaly ':' is the folder separator

if you put : in a file name, it will be converted to /

QString path=QDir::homePath();
QDir dir(path);
dir.mkdir("My:Folder");

will create a folder in the user directory named "My/Folder"
In the Terminal the path looks like that:

/Users/me/My\:Folder

[JonB]

@mpergand
So actually you are showing that Mac behaves like Linux and creates the path as-is, with a :. You cannot have "a folder [...] named "My/Folder" in a Linux file system (which I understand is what Mac uses), / is not a legal character in a single path element under Linux. You seem to show that Mac's "interface" chooses to display a : in a path element as a / character when it "pretty-prints" it for the user, for some purpose?

In any case, the OP reports his issue is under Windows and that is all he cares about.

[J.Hilk]

@mpergand : is valid in the “unix layer”, but it is translated to/from / in the “Mac layers” (i.e. Finder, most file-related dialogs, etc.)
The colon is used as the separator in “HFS paths” and the slash is used as the separator in “POSIX paths” so there is a two-way translation depending on which “layer” you are working with

From smarter people than me

[mpergand]

@J-Hilk said in QUrl::toLocalFile returns a path with an unexpected leading slash:

The colon is used as the separator in “HFS paths” and the slash is used as the separator in “POSIX paths” so there is a two-way translation

It is like that since the begining of OSX