On Thu, Aug 13, 2020 at 11:01:36AM +0200, Christian Schoenebeck wrote: > On Mittwoch, 12. August 2020 16:33:23 CEST Dr. David Alan Gilbert wrote: > > > On macOS there was (or actually still is) even a quite complex API which > > > separated forks into "resource forks" and "data forks", where resource > > > forks were typically used as components of an application binary (e.g. > > > menu structure, icons, executable binary modules, text and translations). > > > So resource forks not only had names, they also had predefined 16-bit > > > type identifiers: > > > https://en.wikipedia.org/wiki/Resource_fork > > > > Yeh, lots of different ways. > > > > In a way, if you had a way to drop the 64kiB limit on xattr, then you > > could have one type of object, but then add new ways of accessing them > > as forks. > > That's yet another question: should xattrs and forks share the same data- and > namespace, or rather be orthogonal to each other. Completely orthogonal. Alternate data streams are not xattrs, and xattrs are not ADS.... Indeed, most filesystems will not be able to implement ADS as xattrs. xattrs are implemented as atomicly journalled metadata on most filesytems, they cannot be used like a seekable file by userspace at all. If you want ADS to masquerade as an xattr, then you have to graft the entire file IO path onto filesytsem xattrs, and that just ain't gonna work without a -lot- of development in every filesystem that wants to support ADS. We've already got a perfectly good presentation layer for user data files that are accessed by file descriptors (i.e. directories containing files), so that should be the presentation layer you seek to extend. IOWs, trying to use abuse xattrs for ADS support is a non-starter. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
