QUrl::toLocalFile returns a path with an unexpected leading slash
-
On Ubuntu and Windows, using Qt 5.12.2, the following snippet
QString myPath = "C:/images/DJI_0069.JPG"; QUrl myUrl = QUrl::fromLocalFile(myPath); std::cout << "URL: " << myUrl.toString().toStdString() << std::endl; std::cout << "toLocalFile(): " << myUrl.toLocalFile().toStdString() << std::endl; std::cout << "path(): " << myUrl.path().toStdString() << std::endl;
has the following output:
URL: file:///C:/images/DJI_0069.JPG toLocalFile(): /C:/images/DJI_0069.JPG path(): /C:/images/DJI_0069.JPG
My concern is that
/C:/images/DJI_0069.JPG
is not a valdid Windows file path whereasC:/images/DJI_0069.JPG
is.My question is: Is the aforementioned leading forward slash expected in the output of
QUrl::toLocalFile
?Clarification. I am primarily interested in the Windows use-case, which is the reason of my post. (Comments about Ubuntu are also welcome, but I am not sure of what one should expect in terms of output.)
Update.
I have made a mistake when reporting the output ofQUrl::toLocalFile
on Windows. After a second round of tests on Windows (Qt 5.12.2), the actual output is confirmed to beC:/images/DJI_0069.JPG
and not/C:/images/DJI_0069.JPG
as I initially and wrongly reported. (the latter is the output ofpath()
).My question is hence answered. I thank all participants for their helpful input and I apologize for the noise.
Luc
-
On Ubuntu and Windows, using Qt 5.12.2, the following snippet
QString myPath = "C:/images/DJI_0069.JPG"; QUrl myUrl = QUrl::fromLocalFile(myPath); std::cout << "URL: " << myUrl.toString().toStdString() << std::endl; std::cout << "toLocalFile(): " << myUrl.toLocalFile().toStdString() << std::endl; std::cout << "path(): " << myUrl.path().toStdString() << std::endl;
has the following output:
URL: file:///C:/images/DJI_0069.JPG toLocalFile(): /C:/images/DJI_0069.JPG path(): /C:/images/DJI_0069.JPG
My concern is that
/C:/images/DJI_0069.JPG
is not a valdid Windows file path whereasC:/images/DJI_0069.JPG
is.My question is: Is the aforementioned leading forward slash expected in the output of
QUrl::toLocalFile
?Clarification. I am primarily interested in the Windows use-case, which is the reason of my post. (Comments about Ubuntu are also welcome, but I am not sure of what one should expect in terms of output.)
Update.
I have made a mistake when reporting the output ofQUrl::toLocalFile
on Windows. After a second round of tests on Windows (Qt 5.12.2), the actual output is confirmed to beC:/images/DJI_0069.JPG
and not/C:/images/DJI_0069.JPG
as I initially and wrongly reported. (the latter is the output ofpath()
).My question is hence answered. I thank all participants for their helpful input and I apologize for the noise.
Luc
-
@lguyot said in QUrl::toLocalFile returns a path with an unexpected leading slash:
My question is: Is the aforementioned leading forward slash expected in the output of QUrl::toLocalFile ?
This looks like a bug. I currently don't have Qt 5.12.2 installed , but both Qt 5.15 and Qt 6.3 do not prepend a slash for toLocalFile:
qDebug() << QUrl::fromLocalFile("C:/images/DJI_0069.JPG").toLocalFile();
"C:/images/DJI_0069.JPG"
-
@lguyot said in QUrl::toLocalFile returns a path with an unexpected leading slash:
My question is: Is the aforementioned leading forward slash expected in the output of QUrl::toLocalFile ?
This looks like a bug. I currently don't have Qt 5.12.2 installed , but both Qt 5.15 and Qt 6.3 do not prepend a slash for toLocalFile:
qDebug() << QUrl::fromLocalFile("C:/images/DJI_0069.JPG").toLocalFile();
"C:/images/DJI_0069.JPG"
@kkoehne said in QUrl::toLocalFile returns a path with an unexpected leading slash:
This looks like a bug.
I guess OP used Windows style path on Linux...
-
@kkoehne said in QUrl::toLocalFile returns a path with an unexpected leading slash:
This looks like a bug.
I guess OP used Windows style path on Linux...
-
@lguyot said in QUrl::toLocalFile returns a path with an unexpected leading slash:
On Ubuntu and Windows,
Are you saying this is the result on both OSes? Linux should handle
C:/...
differently from Windows?@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 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@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? -
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(); }
-
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(); }
@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 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
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 said in QUrl::toLocalFile returns a path with an unexpected leading slash:
On Ubuntu and Windows,
Are you saying this is the result on both OSes? Linux should handle
C:/...
differently from Windows?@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 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).
@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)?
-
@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)?
@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 -
@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@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 separatorif 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
-
@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 separatorif 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
@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 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 separatorif 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
@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 -
@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@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