Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

File.getCanonicalFile "normalizes" more than Path.normalize on Windows #78

Open
alexarchambault opened this issue May 20, 2021 · 2 comments

Comments

@alexarchambault
Copy link
Collaborator

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:

C:\Users\Alexandre>amm -c "println(os.temp())"
Compiling C:\Users\Alexandre\(console)
C:\Users\ALEXAN~1\AppData\Local\Temp\2085325879310438089.tmp

(with ALEXAN~1 rather than Alexandre in the path).

In this case, we have p != os.Path(p.toIO.getCanonicalFile), which is surprising I think:

C:\Users\Alexandre>amm -c "val p = os.temp(); println(p == os.Path(p.toNIO.normalize)); println(p == os.Path(p.toIO.getCanonicalFile))"
Compiling C:\Users\Alexandre\(console)
true
false

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:

C:\Users\Alexandre>amm -c "val p = os.temp(); println(\"NIO: \" + p.toNIO); println(\" IO: \" + p.toIO.getCanonicalFile)"
Compiling C:\Users\Alexandre\(console)
NIO: C:\Users\ALEXAN~1\AppData\Local\Temp\2933120367880475586.tmp
 IO: C:\Users\Alexandre\AppData\Local\Temp\2933120367880475586.tmp

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.

@lefou
Copy link
Member

lefou commented May 21, 2021

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.

@alexarchambault
Copy link
Collaborator Author

if you mean you want to ensure os-lib always uses the long version as canonical path, than I'm all for it.

That's what I meant, yes. I opened #79 for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants