Comment by qwerty456127
7 years ago
> A Win32 path like C:\dir\file gets translated to an NT path like \??\C:\dir\file, where \??\C: is a symlink in Object Manager to a device object like \Device\HarddiskVolume4
Cool! Can the "NT paths" be used directly on Windows? As far as I know the ordinary Win32/NTFS system doesn't even have symlinks and this feels quite a handicap.
New-Item -Path C:\LinkDir -ItemType SymbolicLink -Value F:\RealDir
Note that this is behind a "developper flag", i.e. it needs elevation if you have not checked "developper mode" in the W10 parameters. (I guess they don't want the cost of supporting ordinary people building circular dependencies)
It depends on which API the application uses to pass paths to the OS and whether its path handling library does internal parsing that is or is not aware of those prefixes.
For example rust has support[0] for the magical file path prefixes[1] that can be used to escape path length restrictions, reserved identifiers and some other limitations. This is used by default whenever you normalize a part, which means it has fewer restrictions than windows explorer has by default.
[0] https://doc.rust-lang.org/std/path/enum.Prefix.html [1] https://docs.microsoft.com/en-us/windows/desktop/fileio/nami...
Windows does have symlinks and file junctions. Not sure how these compare to other file systems.
These require user-mode round trips for path traversal, so comparable to FUSE, I believe.
So it is relatively easy to add hooks of your own that get called as if they were file reads; NTFS calls these "Reparse Points". Linux would do this with named pipes.
I am just a user of these things, haven't dug into any implementation details recently, but I guess that the stacks to support these features in Linux and Windows each have their cache etc design decisions that have led to current state of filesystem performance under typical use-cases these days.
I'm not a super expert but I think that is the case and you even need them if you want to use some advanced features like paths that are longer than MAX_PATH or these virtual mount kinds of things.
But IMO it's ugly as hell and just begging for compatibility problems. So don't go there, at least not to get super long paths. 260 bytes should be enough for anybody.
> 260 bytes should be enough for anybody
It happens to be not enough just so damn often.
How did you manage? I've never hit the limit in like 20 years. Maybe 260 bytes means only 130 2-byte characters (I don't even know) and that I might find a little restrictive maybe. In any case I'm tempted to say, just fix your damn paths (if possible). I guess at 80 characters it starts to get unreadable anyway.
9 replies →
Yes they can, though one problems is that because NT paths are less restrictive than Win32 paths, you can create files / directories that you then have trouble doing things with using standard tools
Notably the Windows shell does not support longlong file names, like, at all. The Windows shell and Win32 APIs are also easily confused by files using the NTFS POSIX namespace, which may have \ in their name.