Does OpenZFS support File IDs?
Posted: Mon Dec 14, 2015 6:26 pm
I looked in the wiki and all over the various OpenZFS/ZFS web sites, and they all come from a UNIX perspective which I don't honestly care too much about (despite the fact I started with UNIX). One question which is important from a Mac perspective is if ZFS volumes support FileIDs.
Back in the day (System 7), files and folders on a Mac were referred to by volume and a 32bit value, not a file path. This means that things wouldn't break when moving or renaming files or folders, including aliases.
In case you come from a UNIX background, I'll clue you in on something: aliases are not symlinks or hard links. They are an arbitrary description on how to find a file, and on HFS filesystems could have the volume and ID of a file as opposed to merely the equivalent to a file path. On UFS filesystems they were basically symlinks which are fragile.
(for a long time Cocoa apps couldn't handle files being renamed or moved while open until they started using File IDs internally, although I don't think Apple ever exposed the mechanism in FoundationKit because they're idiots)
Anyway, this is a really nice human interface solution to a problem which won't be fully solved until someone develops an OS that doesn't have files to begin with, and I don't see any mass adoption of ZFS without such a feature.
I undertand that the HFS method for implementing this feature (a catalog file) may be impossible to achieve and the knee-jerk reaction to this may be to dismiss me completely based on that alone, but I would prefer a more constructive conversation than what I've typically experienced in open source projects.
I don't know enough specifics about ZFS to suggest an implementation method, but basically it's a file reference that isn't supposed to break unless the file is deleted. If you hard-link a file (assuming one would ever want to implement hard-links), each hard link has its own file ID in MacOS and behave much like a file path except they don't change.
I honestly don't care as much about case sensitivity, although it's nice to disallow similarly named files to avoid confusion (which I'm sure was the original intent).
Back in the day (System 7), files and folders on a Mac were referred to by volume and a 32bit value, not a file path. This means that things wouldn't break when moving or renaming files or folders, including aliases.
In case you come from a UNIX background, I'll clue you in on something: aliases are not symlinks or hard links. They are an arbitrary description on how to find a file, and on HFS filesystems could have the volume and ID of a file as opposed to merely the equivalent to a file path. On UFS filesystems they were basically symlinks which are fragile.
(for a long time Cocoa apps couldn't handle files being renamed or moved while open until they started using File IDs internally, although I don't think Apple ever exposed the mechanism in FoundationKit because they're idiots)
Anyway, this is a really nice human interface solution to a problem which won't be fully solved until someone develops an OS that doesn't have files to begin with, and I don't see any mass adoption of ZFS without such a feature.
I undertand that the HFS method for implementing this feature (a catalog file) may be impossible to achieve and the knee-jerk reaction to this may be to dismiss me completely based on that alone, but I would prefer a more constructive conversation than what I've typically experienced in open source projects.
I don't know enough specifics about ZFS to suggest an implementation method, but basically it's a file reference that isn't supposed to break unless the file is deleted. If you hard-link a file (assuming one would ever want to implement hard-links), each hard link has its own file ID in MacOS and behave much like a file path except they don't change.
I honestly don't care as much about case sensitivity, although it's nice to disallow similarly named files to avoid confusion (which I'm sure was the original intent).