Hacker News Reader

Comment by eduction | Hacker News Reader

The fact these paths are considered at all "weird" just underlines how much we live in a Unix world.

Filesystem paths used to all be weird in the sense that there was more OS diversity. I'm sure some people here remember that classic MacOS paths used colon as the separator:

  Hard Drive:My Folder:My Document

VMS (designed by the same person as Windows NT by the way) had paths that looked like this (per Wikipedia):

  NODE"accountname password"::device:[directory.subdirectory]filename.type;ver

RSTS/E had [project,user] in the filename.

Multics paths:

  >dir1>dir2>dir3>filename

Apple Lisa used dashes as the separator. Etc.

View on HN

As someone who grew up with Windows, I don't think these paths are that weird at all. Drive letter working directories just make sense, for example. The weirdest part is the (edit: HFS) compatibility mode (file.ext:substream).

One fun surprise is that because of codepage reasons, the Windows will use ¥ as a path separator in Japanese. In Korean, it's ₩. These characters represent U+005C, which is \ in Latin-compatible character sets.

that's amazing. and point taken that Windows is probably extra weird due to its longevity, evolution, and backward compatibility.

Windows is younger than Unix, and Unix filesystem evolved has "evolved less" due to getting it right the first time, removing backward compatibility issues.

that's not a compatibility thing, is it? it's just the alternate streams feature that NTFS implemented.

NTFS implemented it to be compatible with Mac. They then started using it for storing the Mark of the Web and other special system properties, but practical came much later.

It's pretty weird that Windows drives use random letters instead of just the name of the disk.

It’s a legacy from the IBM CP/CMS days.

First floppy drive was A, Second B, and when internal Hard Drives came along they defaulted to C to be compatible with computers that had at least 2 disk drives.

https://en.wikipedia.org/wiki/Drive_letter_assignment?wprov=...

If I rembember correctly, you could use the B drive even if you have just one unit. It was useful to copy files from one disk to another, even if you didn't had an hard drive as temporary storage

This was ultimately inherited from IBM’s CMS system [0] (from 1968 I believe) via CP/M and DOS.

[0] https://en.wikipedia.org/wiki/CMS_file_system

I tend to use /dev/sda1 more than /dev/disk/by-path/pci-0000:00:17.0-ata-1.0-part1. Disk names are nice, but also often longer than 8 characters and usually not very unique.

Starting from A and iterating on through Z makes sense, for an OS that's designed for two drives at most. /dev/sda and /dev/sdb are no less arbitrary than A: and B:.

One major difference was that Unix was used on big servers and couldn't fit itself onto a single disk, so /usr had to be created. DOS and Windows never needed a second drive to boot, so they didn't need to embed their resources into the drive hierarchy.

Of course, you can mount NTFS volumes at any directory you wish since at least somewhere in the early 2000s. Very few people do it, but you can!

For example:

    $Disk = Get-Disk 2
    $Partition = Get-Partition -DiskNumber $Disk.Number
    $Partition | Add-PartitionAccessPath -AccessPath "G:\Folder01"

> The weirdest part is the HPFS compatibility mode (file.ext:substream).

HPFS had extended attributes, but not substreams. You are thinking about HFS; substreams were added to NTFS to support storing resource forks on network shares used by Macs.

Oops, you're right, added an extra letter to the acronym.

> I'm sure some people here remember that classic MacOS paths used colon as the separator

In modern macOS (previously OS X), you’ll eventually bump into those if you need to work with paths in AppleScript. You have to specify when you’re using a POSIX path so it is properly converted. Example:

    $ osascript -e 'POSIX file "/System/Applications/Mail.app/Contents/MacOS/Mail"'
    => file Macintosh HD:System:Applications:Mail.app:Contents:MacOS:Mail

Doesn't MacOS translate "/" into ":" sometimes in save dialog boxes when you type in a filename?

Go in the Finder and try to change a file name to have a colon. macOS will tell you it can’t do it.

Now change it to have a forward slash. macOS will happily abide.

Finally, look at that file’s path in a terminal. Where the Finder shows a forward slash, the terminal will show a colon.

Redoing the AppleScript example:

    $ osascript -e 'POSIX file "/tmp/file with : forward slash.txt"'
    => file Macintosh HD:private:tmp:file with / forward slash.txt

As another example, with ADFS (Advanced Disk Filing System) on the Acorn/BBC computer family, the root directory was specified with `$`, and the directory separator was `.`.

    $dir1.dir2.dir3.filename

A full path on RISC OS included the filesystem:

  ADFS::IDEDisc4.$.Games.!Repton.Arctic

ADFS is the filesystem, IDEDisc4 is the disc name, $ is the root directory, Games is a subdirectory, !Repton is an application directory (since it begins with !) and Arctic is a file within the application directory, not normally referenced by users.

  Resources:$.Apps.!Edit

is the application !Edit from the built-in ROM.

macOS still uses colons as the path separator, it just does a great job of hiding them from the user. If you try to open a file with a slash in its name in a shell, though, you'll need to use a colon.

I suspect that it is the other way around and the Finder and standard dialogs (both of which use slashes as path separator when you type the path) simply shows colons in filenames as slashes.

macOS's kernel has BSD roots, so I'd be surprised if its VFS code accepts anything other than unix paths. Just a guess, but it's probably the Cocoa APIs accepting colon paths and translating it to unix paths internally.

> NODE"accountname password"::device:[directory.subdirectory]filename.type;ver

Interesting. When you think about it, that doesn't look all that different from:

scheme://user:password@host:port/directory/filename.type?key=value&key=value#fragment

which is arguably the most common kind of "file path" in use today.

I was parsing paths into an array of dirs recently.

The `/` root dir is quirky. You can’t just do `dirPath.split(‘/‘)`. You have to handle it as a special case. Would be easier if it had a special name. Like `$/dir1/dir2`.

Or am I missing something.

thank goodness unix has cleared this up, with paths, mountpoints, overlay filesystems, chroot, device trees, bind mounts, loopback mounts and probably a few I forgot...

(sort of amazing the original premise, and the exceptions and workarounds you gradually accumulate and take for granted)

Reply on news.ycombinator.com