The comedy of this is that there are actually plenty of FSes common to all three of these OSes, they're just not considered "modern"; FAT32 is still the most commonly used FS for interop, even as it shows its age with poor support for very large files (2+GB) and file systems, but you also have ISO(9660) and (the best answer we currently have) UDF supported by all three OSes natively and openly without patents or other licensing restrictions. The latter two are not commonly used as read/write filesystems, but have zero inherent restrictions on being able to be used in such a way.

However, the problem has been largely supplanted by having a fast and well-functioning network and people moving to "The Cloud" for, well, everything. It's hard to know how much of the Great Cloud Migration is caused by these kinds of intentionally engineered interoperability fails, especially the monumentally stupid exFAT patent... It's interesting to ponder given the people likely to complain the most about filesystems today are people who want to move large files (4+GB) between OSes without anguish, where the network is still just too slow to handle the task well.

Myth 2 was a popular testing media in those days due to Apple and PC endian differences. As I recall Bungie did some clever crafting on the structures to share some of the media between platforms while keeping binaries separated. Even had a fun picture of soulblighter in Finder through icon trickery.

-wrote commercial CD mastering and storage software many many moons ago

However, it is not, not even close to, a decent file system. (And that's before we even get into RRIP and Joliet. /shudder)

And IIRC, ISO9660 has issues with being written - the path table needs to be ordered. Yes, you can make it modifiable on the fly, but the pain to do so is just not worth it.

Wasn't there a major problem in that all the operating systems supported different versions of the UDF standard? And most of them treat it as an optical disk format, so I wouldn't be surprised if some of them acted like it was read-only.

+1. The great benefit of the "cloud" and the internet in general is as an escape from vertically integrated silos. Which is why all the big players are frantically trying to rebuild some kind of lock-in along different lines.

Novell's NWFS and NSS filesystems have always supported trustee assignments that flow recursively at the point of access rather than the point of administration. Unless you have used either of those as an administrator involving say 1000s of people and groups and millions of files then you will not appreciate this distinction.

On both Windows and Linux, if you have to make changes to FS perms, then the ACLs have to be made to each object - file or folder. On NWFS and NSS, you only do it at a point (say a directory) and then it will recurse automatically unless blocked by an IRF (Inheritable Rights Filter - bloody stupid but there if you really need it)

The end result is that making a change to a tree of files on any Unix or Windows FS takes from seconds to hours. On NWFS or NSS it generally takes seconds (for the screen to refresh).

I have never quite understood why Linux or Windows admins (I'm both) have put up with the rubbish ACLs and implementations of "modern" filesystems. Oooh RAID in software and snapshots - oh how nice.

The POSIX ACLs thing is genuinely shit, very outdated and absolute rubbish. This is the 21st century FFS. Why on earth should you wait as each file in a collection that you have deemed as belonging to sales but be readable by fred be stamped as such? Why should users be able to see the path down to a point where they have access? Why on earth should 21st C admins have to watch a change of security requirements take from a few seconds to hours/days?

Modern FS's are so NOT 1990s and what a shame.

NTFS has perms inheritance (and overriding) since forever, did you know that?

>The end result is that making a change to a tree of files on any Unix or Windows FS takes from seconds to hours. On NWFS or NSS it generally takes seconds (for the screen to refresh).

Painless administration requires careful planning, no matter what OS you're using.

Chances are you will open the file more often than you will change ACLs so they chose the latter which makes sense.

This article is about the problems it causes (note that in Vista they changed the design so when moving a subtree the system automatically propagates permissions, removing a major cause of desyncs)

  setfacl g:admins:rw g:staff:r somefile

  getfacl somefile

Every object in the OS that can be represented by an OS handle, has security permission attached to it.

Files, registry, sockets, drivers,.....

Instead of moving storage devices around, you might consider setting up a NAS and transferring files over the network. It doesn't work for every use-case, but it might be a viable alternative to many use-cases.

There's a Linux driver for it, but it's proprietary: https://www.paragon-software.com/home/refs-linux/

Mostly that's the software's fault, mistakenly assuming anything "not NTFS" is FAT32 and insisting I need to "upgrade" my drives, even though I'm only using it as project storage.

I honestly don't know why user mode software can tell what format the volume is in, and wouldn't just expect the OS to handle it or provide various feature flags like VOLUME_SUPPORT_LARGE_FILES or so.