site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Am 05.03.2006 um 00:13 schrieb Jordan K. Hubbard: 1. That the source and the target for any operation may or may not support EAs, yet heterogeneous operations can't lose data. 2. That creating, editing, renaming, copying and deleting files all need to be able to keep data and metadata together, fully cognizant of the limitations posed by item #1. Maybe there's a way to handle this at the file system level, even for file systems not traditionally supporting EAs. EAs are/can be a thing of the file system driver, even if you store files/metadata in a way readable by a driver not supporting metadata. To take an example on UFS: Creating a file on a Macintosh would create a "file" entry and a "._file" entry as necessary. Not at the system API level, but at the file system level. The file system would hide "._file" on the Mac, making UFS appearing as EA supporting file system. No tool would ever get the idea to do something nasty with this "._file" pseudo-file as it's transparent to the API level. This is implemented, but not currently enabled for UFS. Mounting the same file system on a Linux/BSD/whatever OS would make "._file" appear as a completely separate file from "file", fully native to that other OS. Disadvantages: - File listings of the same volume on different OSs show a different number of files. - File archiving (tar etc.) and custom copy protocols (rsync etc.) would still have to handle EAs themselves when copying to/from non- Mac OSs. This is the "hard work" to which Jordan alludes, and a good deal of the work has been done. Advantages: - There's no need to tweak the basic CLI tools as all file systems appear as supporting EAs on the Mac. This is a remarkably nontrivial problem when you are not guaranteed for example the ordering of incoming ._ files, or even that they still map to the other files you are receiving. Other tools that manipulate files within the system domain still have to be modified; tools like cp, mv, and any application that makes backup or autosave files must learn to manage EAs and ACLs. - Mapping for network file systems can be done at the network file system driver level, so NFS etc. would still appear as supporting EAs on the Mac, not supporting EAs on other OSs. = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Sun, 5 Mar 2006 11:42:51 +0100, Markus Hitter <mah@jump-ing.de> wrote: This is how Mac OS currently handles the situation for filesystems which inherently cannot support EAs. The ._ files are generated and managed by the VFS, but they have the same format so that if the volume is subsequently moved to a platform which is ignorant of them and they are then exported by either a filesystem (e.g. NFS) or application (e.g. rsync) they can be detected and managed accordingly. On the contrary, there is substantial work that has to be replicated so that tools that serialise the filesystem format (tar, cpio, pax, rsync, scp, zip, unzip, ftp, tftp, etc. etc.) can handle the production and consumption of ._ files. The approach taken is actually more modular than this. VFS plugins are only required to know anything about EAs and ACLs if their particular filesystem supports them in some fashion. Ignorant filesystems can simply set a bit indicating that administratively EAs or extended security is desired and the VFS will handle the details transparently. This email sent to site_archiver@lists.apple.com