Bundle (macOS) - Wikipedia

Bundle (macOS) - Wikipedia:



Many years ago (like, in the 1980s) folks at Gould and UIUC were wondering if we should extend Gould UNIX to support "structured files", like MacIntosh resource forks.



Way back then I said "No, UNIX already supports structured files: directories." With arbitrary metadata.



Similar, a newsgroup discussion on a similar topic - long enough ago that it waas net.* - Chris Torek was involved IIRC - it was pointed out that a tar archive is a structured file, equivalent to a directory.



This is well and good.



MacOS bundles are this concept, carried forward.  MacOS bundles are visible to ordinary UNIX apps as directories, but if you have the appropriate libraries they behave as structured files.



But if you don't have the right libraries, it is easy to damage such "bundles = structured files are directory trees". Tools like "find" traverse into them, etc.



Document formats such as Java JAR files and OpenDocument .odt/.odf files continue the "structured files are archives" meme. Using ZIP, in this case, because ZIP was commonly available on Windows PCs, even though zip does not support as much UNIX metadata the way tar files do.



It is harder to accidentally damage such a "structured files are archives" file. Standard UNIX tools don't look inside.



If you have a user level filesystem like FUSE, you can look inside the archive by mounting it, and use standard tools to manipulate it.



Heck - I wish that .git and .hg storage in repositories worked this way.



But archives are slower to manipulate that directory trees.



I want the best of both worlds - and better.



I want it to be transparent whether "structured file is directory tree" or "structured file is archive".



I want such a structured file to appear as a file (no internal structure) by default.



Possibly with a default data fork.



But I want it to be possible to "mount" such a structured file, whether directory tree or archive, so that standard tools can traverse.  Such a mount should not be global, but user, or better, context specific.  A la Plan9 namespace.



Special privilege should be required.  (No, not kernel, but not any user.)



This way we could distinguish between users and tools that just know how to copy or open the structured file "atomically", and those allowed to do more major surgery.









'via Blog this'