Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A tale of two path separators

alexwlchan.net

Post reply on HN
Print view View original

31–38 of 38 posts

Re: A tale of two path separators

#31

Post by skissane »

syncsynchalt wrote: post #18
Kwpolska wrote: post #15

Earlier quoted context omitted.

But they do see / or : in file names, and the interesting question is which one it is today on which filesystem.

The filesystems of macOS are particularly opinionated, much more than most Unices which tend toward "anything is allowed [and usually preserved] except \0 and /". macOS supports case-insensitivity[0] and performs unicode normalization[1] on filenames, and decomposes name data to an extent that the question "what does the fs see" is a bit moot. With that said, the internal storage of filenames in APFS are a nul-termin…

> macOS supports case-insensitivity

Well, strictly speaking Linux does too, since it supports mounting local or remote filesystems with this feature

For a long time, the real distinction was that “native” Linux filesystems didn’t support it, but “foreign” ones did. However, nowadays even some of the “native” filesystems have optional support for case-insensitivity (e.g. casefold feature on ext4)

The real difference now: on macOS, it is normal to have this feature turned on, exceptional to have it disabled; on Linux, it is the other way around

Re: A tale of two path separators

#32

Post by skissane »

momoraul wrote: post #13

Another Windows oddity: each drive letter has its own current directory. D: doesn't mean the root of D:, it means "wherever you last were on D:". Same with C:foo, which is relative to C:'s current directory. DOS baggage that's still around.

> Another Windows oddity: each drive letter has its own current directory

For NT-based Windows: only in cmd.exe, and other apps which choose to support the same convention. The NT/Win32 API only supports a single per-process directory

There is actually space in NT data structures to store per-drive current directory, but no released version has ever used it. I think they planned to implement the idea in NT itself (or NT’s implementation of Win32), but then settled on just having a single current directory per-process, and faking the old behaviour in cmd.exe using environment variables

By contrast, Windows 1.x/2.x/3.x/9x/Me retained the old DOS behaviour of per-drive current directories, so Win32 does actually have them if you mean the Win32s or 9x/Me implementations of Win32.

Separately, both Linux and macOS support per-thread current directories separate from the per-process current directory, although by default all threads use the process-wide current directory. Last I checked, the macOS implementation was a bit more sophisticated, in that on Linux once the link between process and thread current directory was severed, it was gone for the lifetime of the thread; by contrast, macOS has an API to re-establish it.

Re: A tale of two path separators

#33

Post by chrismorgan »

ChrisSD wrote: post #27
chrismorgan wrote: post #19

Earlier quoted context omitted.

And you need `cd /d` to switch drives. This was how I rendered a Windows computer non-bootable for the first time. Ran Command Prompt as admin (because I was logged in as a user that didn’t have write access to D:\backups), and it starts in a rather important directory, then: C:\WINDOWS\system32>cd D:\backups\some-huge-directory C:\WINDOWS\system32>del /s * Oops. I learned to look twice before running a big dangerous…

Or you could use powershell and avoid the issue ;). Though nowadays system files should be protected even from admin and even if you do manage to delete them, Windows can restore them.

PowerShell didn’t quite exist back then!

Re: A tale of two path separators

#34

Post by p_l »

Kwpolska wrote: post #15
p_l wrote: post #12

Earlier quoted context omitted.

Filesystems usually do not see path separators at all, it's something handled at VFS level

But they do see / or : in file names, and the interesting question is which one it is today on which filesystem.

You can imagine many internal APIs as taking "look up this from directory ". Surprisingly often the only practical limit is that the name does not contain NULL bytes.

Path separators, whether to accept directory entries with path separator in them, etc. are usually handled layer above

Re: A tale of two path separators

#36

Post by momoraul »

skissane wrote: post #32
momoraul wrote: post #13

Another Windows oddity: each drive letter has its own current directory. D: doesn't mean the root of D:, it means "wherever you last were on D:". Same with C:foo, which is relative to C:'s current directory. DOS baggage that's still around.

> Another Windows oddity: each drive letter has its own current directory For NT-based Windows: only in cmd.exe, and other apps which choose to support the same convention. The NT/Win32 API only supports a single per-process directory There is actually space in NT data structures to store per-drive current directory, but no released version has ever used it. I think they planned to implement the idea in NT itself (or…

Ah, fair. On modern Windows it's really cmd.exe faking it with env vars, not the API. Didn't know NT reserved space for per-drive CWDs and then never used it.

Re: A tale of two path separators

#37

Post by momoraul »

chrismorgan wrote: post #19
momoraul wrote: post #13

Another Windows oddity: each drive letter has its own current directory. D: doesn't mean the root of D:, it means "wherever you last were on D:". Same with C:foo, which is relative to C:'s current directory. DOS baggage that's still around.

And you need `cd /d` to switch drives. This was how I rendered a Windows computer non-bootable for the first time. Ran Command Prompt as admin (because I was logged in as a user that didn’t have write access to D:\backups), and it starts in a rather important directory, then: C:\WINDOWS\system32>cd D:\backups\some-huge-directory C:\WINDOWS\system32>del /s * Oops. I learned to look twice before running a big dangerous…

Oof, cd silently staying on the wrong drive and then del /s is the worst possible version of this. /d the hard way.

Re: A tale of two path separators

#38

Post by skissane »

momoraul wrote: post #36
skissane wrote: post #32

Earlier quoted context omitted.

> Another Windows oddity: each drive letter has its own current directory For NT-based Windows: only in cmd.exe, and other apps which choose to support the same convention. The NT/Win32 API only supports a single per-process directory There is actually space in NT data structures to store per-drive current directory, but no released version has ever used it. I think they planned to implement the idea in NT itself (or…

Ah, fair. On modern Windows it's really cmd.exe faking it with env vars, not the API. Didn't know NT reserved space for per-drive CWDs and then never used it.

> Didn't know NT reserved space for per-drive CWDs and then never used it.

RTL_USER_PROCESS_PARAMETERS has a field “RTL_DRIVE_LETTER_CURDIR CurrentDirectores[32]” (note the misspelling). And then RTL_DRIVE_LETTER_CURDIR is defined as:

    typedef struct _RTL_DRIVE_LETTER_CURDIR
    {
         WORD Flags;
         WORD Length;
         ULONG TimeStamp;
         STRING DosPath;
    } RTL_DRIVE_LETTER_CURDIR, *PRTL_DRIVE_LETTER_CURDIR;
But, AFAIK, Microsoft has never shipped anything that uses it. My own impression is this was the original design for handling compatibility with the DOS current directory behaviour, but they ended up deciding on doing it in cmd.exe instead. And of course, NTVDM and 16-bit Windows app support, but I think that just used the 16-bit DOS code and its associated data structures.

https://www.geoffchappell.com/studies/windows/km/ntoskrnl/in...

Post reply on HN