On Thu, May 25, 2023 at 08:49:47PM +1000, ronnie sahlberg wrote:
just took a look at how the ntfs-3g module is handling this. It was an option streams_interface=value, which allows "windows", which means that the alternative data streams are accessable as-is like in Windows, with ":" being the separator. This might be a nice option for cifsfs also. That option would just be usable if no posix extensions are enabled of course.We could. But that is a windowism where ':' is a reserved character but which is not a reserved character in unixens. For example: You have the file "foo" with stream "bar" and you have another normal file "foo:bar" Which one does open("foo:bar") give you? The openat/... semantics that solaris uses provides an elegant and unambiguous semantics for it. You want to open stream bar on file foo? 1, fh = open("foo") 2, sh = openatf(h, "bar") There are at least two non-windows related filesystems that support something similar to ADS, solaris filesystem and apples filesystem(s) so it would be nice to have a neutral API where an application can use the same code to access streams be they cifs/ntfs/solarisfs/applefs/...other... Steve, I think this would be a good discussion topic for vfs meetings. Is it desirable to bless an api in the vfs to do alternate data streams? There are at least 4 filesystems that provide this feature, 3 of which are still very popular and common today. One approach would be to mimic the interface that solaris provides with openatfile-fd, "stream-name")
Solaris is dead, dead, dead. We should not resurrect the warts of that thing in Linux.
But that would not just be a filesystem change but also a VFS change since it would suddenly accept passing a file-fd as argument as a valid option (for those filesystems that have signalled alternative stream support?) while the vfs currently only allows openat() on a directory-fd.
I never thought I'd be calling on Christolph Hellwig to squash such a horror before it emerges, but I'm CC:ing him on this email in the hope that he will :-).
ADS as a concept is really powerful and could be enormously useful as way to attach metadata to a file object in a standardized way. There are very many use-cases where having a file that embedded both the executable as well as various other types of data but still be able to treat it as a single self-contained file from an end-user perspective.
Please give real examples of something for which this is *essential*. Not "could be.. useful". Hard mode. Windows has yet to find such an example :-). One more datapoint: "still be able to treat it as a single self-contained file from an end-user perspective." - please enumerate every single tool and archiving program that will need to be changed to treat a file containing alternate data streams as "a single self-contained file".
This should be discussed and we should probe the vfs folks about what they think about it.
I hope they just say no :-).
