Live data from Hacker News

A tale of two path separators

alexwlchan.net

21–30 of 38 posts

Re: A tale of two path separators

#21
post #14
post #9

I was expecting the story of the magical ¥ path separator

Would you mind sharing a related link? I'm finding it to be impossible to search "¥ path separator", the ¥ is stripped out by like every search engine even when quoted

Search for "yen sign path separator".

Re: A tale of two path separators

#22

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…

> a file named "schön" (s-c-h-combining¨-o-n)

Combining marks come after the character they modify, btw. (Presumably thanks to support from things like harfbuzz, modern systems will happily put two dots above an h.)

Re: A tale of two path separators

#24
post #14
post #9

I was expecting the story of the magical ¥ path separator

Would you mind sharing a related link? I'm finding it to be impossible to search "¥ path separator", the ¥ is stripped out by like every search engine even when quoted

https://news.ycombinator.com/item?id=29177000

Re: A tale of two path separators

#25
post #22

Earlier quoted context omitted.

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…

> a file named "schön" (s-c-h-combining¨-o-n) Combining marks come after the character they modify, btw. (Presumably thanks to support from things like harfbuzz, modern systems will happily put two dots above an h.)

scḧon

Re: A tale of two path separators

#26
Classic Mac OS aliases are similar to shortcuts on Windows; they are not symbolic links but rather actual files that record the path to the target.

I want to call such aliases "normal" files, as opposed to a link, but the path description is saved in the Resource Fork of the file, not the Data fork.

Resolving an alias can involve network path traversal. You can make an alias of a file on an AFP volume and save it locally, and the next time you use the alias the volume will be auto mounted if necessary. I think you can get similar behavior from other OS configurations.

I seem to recall that if you move or rename a file, the system will update the alias for you. It can't always figure this out. But it will try. That's something you might not see elsewhere...

I've forgotten why AppleScript returns alias objects instead of strings.

Re: A tale of two path separators

#27

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…

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.

Re: A tale of two path separators

#28
post #20

It took me a long time to understand why colon wasn't a valid character for file names on Mac and I still find the colon separator to be the least visible these days. Finder can display paths with the forward slash separator (defaults write com.apple.finder _FXShowPosixPathInTitle -bool YES), and yet forward slash may be used in a file name created through Finder as noted in the post, while colon cannot (which is not…

You still have to worry about colons on Linux; while they're valid in file and folder names, they prevent folders from being put on PATH and understood properly. (Other characters of course cause usability problems and are potentially even a security vulnerability depending on the terminal. But they're still "valid".)

Stock macOS uses a bash or zsh shell in the terminal (depending on the OS version), so the same points of caution hold there as well.

Re: A tale of two path separators

#30
post #4

Earlier quoted context omitted.

Current macOS Finder let's you name files with a slash in them, rendered as a : in the terminal.

I think that the slash might be the rendering though? If you $ touch "foo:bar" In the Terminal, then Finder renders it as foo/bar . So who is lying, how is it stored in the directory entry in APFS itself?

APFS stores it as "foo:bar". (I don't think the filesystem itself cares what's in a name.)
Post reply on HN