5 ms·

Is “..” the official way to get a parent directory on Windows? Or do they have some other API and the “..” is just a nod to UNIX compatibility?

wruza 4y ago
Hold your giggles until you learn that windows MAX_PATH is only 260 characters. Not just filename, the entire path. Unless an app uses \\?\ prefixes and special API for navigation, which is rare, ime.
metadat 4y ago
".." works fine in Windows environments.
delta_p_delta_x 4y ago
> on Windows There are many ways to access the filesystem on Windows. CMD.exe and PowerShell respect `..` to go to the parent directory, as does MSVC C++17 with `std::filesystem`, and .NET, with `System.IO.Path.Combine(String, String)`. In PowerShell and .NET, there's also the `System.IO.DirectoryInfo.Parent` property, and of course, the equivalent `std::filesystem::path::parent_path` in MSVC C++.
- TeMPOraL 4y ago
  There's an important consideration 'ChrisSD mentions here[0], i.e. whether resolving ".." is done lexically or by querying the filesystem. You may get different answers in each case if e.g. you try to resolve /foo/bar/../baz, when /foo/bar is a symlink to a different directory. At least in case of std::filesystem, everything in std::filesystem::path is purely lexical. So, to get actual parent of some path, you'll need to go through std::filesystem::directory_entry and std::filesystem::read_symlink(). -- [0] - https://news.ycombinator.com/item?id=33312712 https://news.ycombinator.com/item?id=33312712
ChrisSD 4y ago
The difference between Windows ".." and unixy ".." is that the former is done lexically whereas the latter is a link to the canonical parent. E.g. on Windows: "path\to\..\file" is always the equivalent of "path\file". Whereas on unixy systems "path/to/../file" may take you to a completely different parent directory. That said, Unix shells can muddy the waters a bit. They may choose to act lexically with some commands.
- rollcat 4y ago
  > E.g. on Windows: "path\to\..\file" is always the equivalent of "path\file". Whereas on unixy systems "path/to/../file" may take you to a completely different parent directory. Worth noting here that Plan 9 is using lexical names[1], and the Go standard library offers the function path.Clean[2] to achieve similar results. If your language/library/OS doesn't offer this behavior by default, it's likely a good idea to add/reimplement this function, unless you need bug-for-bug compatibility. [1]: https://web.archive.org/web/20220824070659/https://9p.io/sys/doc/lexnames.html https://web.archive.org/web/20220824070659/https://9p.io/sys... [2]: https://golang.bg/pkg/path/#Clean https://golang.bg/pkg/path/#Clean
wizofaus 4y ago
It seems the only official native API for getting the parent directory from a known (full) path is PathCchRemoveFileSpec. But certainly C# and other similar platforms have functions doing similar things, and usually don't require a system API call anyway, it's just string manipulation - unless of course the path is relative to the current directory.

wruza 4y ago

Hold your giggles until you learn that windows MAX_PATH is only 260 characters. Not just filename, the entire path. Unless an app uses \\?\ prefixes and special API for navigation, which is rare, ime.

metadat 4y ago

".." works fine in Windows environments.

delta_p_delta_x 4y ago

> on Windows There are many ways to access the filesystem on Windows. CMD.exe and PowerShell respect `..` to go to the parent directory, as does MSVC C++17 with `std::filesystem`, and .NET, with `System.IO.Path.Combine(String, String)`. In PowerShell and .NET, there's also the `System.IO.DirectoryInfo.Parent` property, and of course, the equivalent `std::filesystem::path::parent_path` in MSVC C++.

TeMPOraL 4y ago
There's an important consideration 'ChrisSD mentions here[0], i.e. whether resolving ".." is done lexically or by querying the filesystem. You may get different answers in each case if e.g. you try to resolve /foo/bar/../baz, when /foo/bar is a symlink to a different directory. At least in case of std::filesystem, everything in std::filesystem::path is purely lexical. So, to get actual parent of some path, you'll need to go through std::filesystem::directory_entry and std::filesystem::read_symlink(). -- [0] - https://news.ycombinator.com/item?id=33312712 https://news.ycombinator.com/item?id=33312712

ChrisSD 4y ago

The difference between Windows ".." and unixy ".." is that the former is done lexically whereas the latter is a link to the canonical parent. E.g. on Windows: "path\to\..\file" is always the equivalent of "path\file". Whereas on unixy systems "path/to/../file" may take you to a completely different parent directory. That said, Unix shells can muddy the waters a bit. They may choose to act lexically with some commands.

rollcat 4y ago
> E.g. on Windows: "path\to\..\file" is always the equivalent of "path\file". Whereas on unixy systems "path/to/../file" may take you to a completely different parent directory. Worth noting here that Plan 9 is using lexical names[1], and the Go standard library offers the function path.Clean[2] to achieve similar results. If your language/library/OS doesn't offer this behavior by default, it's likely a good idea to add/reimplement this function, unless you need bug-for-bug compatibility. [1]: https://web.archive.org/web/20220824070659/https://9p.io/sys/doc/lexnames.html https://web.archive.org/web/20220824070659/https://9p.io/sys... [2]: https://golang.bg/pkg/path/#Clean https://golang.bg/pkg/path/#Clean

wizofaus 4y ago

It seems the only official native API for getting the parent directory from a known (full) path is PathCchRemoveFileSpec. But certainly C# and other similar platforms have functions doing similar things, and usually don't require a system API call anyway, it's just string manipulation - unless of course the path is relative to the current directory.