Closed RivenSkaye closed 1 month ago
Looks like this was just stabilized in the latest Rust release, that would explain why I'd never heard of absolute
before. But this behavior does seem a lot more intuitive.
Yeah, the only reason I included a cfg macro snippet is because of the different behavior between OSes here. I expect some things on Linux to break if they suddenly don't get canonicalized paths anymore, considering the lack of handling symlinks and e.g. ..
there
I would expect linux symlinks to be less of an issue, since linux filesystems should handle that natively (e.g. if a Vapoursynth script has a symlink in its source path, that should just work). I'll do some testing just to make sure.
My worries wrt Linux are more about not sanitizing .
and ..
which isn't always supported at the filesystem level, as well as being a PITA when debugging code. Sure, accessing the file should work in most cases, but I'd rather be safe than sorry. Especially considering the if cfg!
block should be optimized out to either call depending on the target in the MIR optimization pass
Currently the source file for vapoursynth is being canonicalized immediately (
std::fs::canonicalize
) which creates extended (UNC-like) paths on Windows. Depending on the compiler and functions used, code written in other languages may fail to understand these.Changing the line
let source = std::fs::canonicalize(source)
to usestd::path::absolute
instead would fix and prevent future occurrances of e.g. vapoursynth/bestsource#59 altogether.