Re: Why no work on rsync?
Re: Why no work on rsync?
- Subject: Re: Why no work on rsync?
- From: Mike Smith <email@hidden>
- Date: Sun, 5 Mar 2006 12:16:45 -0800
On Sun, 5 Mar 2006 11:42:51 +0100, Markus Hitter <email@hidden>
wrote:
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.
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.
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.
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.
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.
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.
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden