You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
That originates from the different handling of the 8.3 / long paths, calling java.io.File.getCanonicalFile on those files rather than java.nio.file.Path.normalize returns different paths:
It seems File.getCanonicalFile calls GetLongPathName while Path.normalize doesn't.
I don't know if anyone has an opinion about this. I'd argue the paths returned by getCanonicalFile are more "normal", and should be used by default here. In particular, I've had issues with a downstream library calling getCanonicalFile at some point, which returned apparently different paths than os-lib.
I can send a PR to replace the few uses of Path.normalize by File.getCanonicalFile if everyone is fine with it.
The text was updated successfully, but these errors were encountered:
I only use Windows very rarely and didn't get contact to the old "8.3" format for ages. So, to me using the "8.3" format as some canonical format can't be right, because of the information loss and also as it might depend on the current state of the disk. I'm not exactly sure what you are proposing, but if you mean you want to ensure os-lib always uses the long version as canonical path, than I'm all for it.
My Windows user name is
Alexandre
, which is more than 8 characters long. Creating temporary directories gives me paths which are in "8.3" format:(with
ALEXAN~1
rather thanAlexandre
in the path).In this case, we have
p != os.Path(p.toIO.getCanonicalFile)
, which is surprising I think:That originates from the different handling of the 8.3 / long paths, calling
java.io.File.getCanonicalFile
on those files rather thanjava.nio.file.Path.normalize
returns different paths:It seems
File.getCanonicalFile
callsGetLongPathName
whilePath.normalize
doesn't.I don't know if anyone has an opinion about this. I'd argue the paths returned by
getCanonicalFile
are more "normal", and should be used by default here. In particular, I've had issues with a downstream library callinggetCanonicalFile
at some point, which returned apparently different paths than os-lib.I can send a PR to replace the few uses of
Path.normalize
byFile.getCanonicalFile
if everyone is fine with it.The text was updated successfully, but these errors were encountered: