Re: Why no work on rsync?
Re: Why no work on rsync?
- Subject: Re: Why no work on rsync?
- From: "Jordan K. Hubbard" <email@hidden>
- Date: Sat, 4 Mar 2006 15:13:59 -0800
On Mar 4, 2006, at 2:37 PM, Boyd Waters wrote:
What? I find it difficult to believe that some research into EA
preservation did not yield prior work. But that would be heavily
dependent upon the timing, as this seems to be an active area of
research. Alas.
Well, the timing would have been very early Tiger, so I'm not saying
our knowledge is entirely up to date here. It's always worth another
look, but at the time, there wasn't much (well, ANYTHING) in the CLI
space.
ReiserFS version 4 has extensive support for per-file metadata.
They still argue about the best way to represent such metadata, and
the pseudo-subdir approach that I've seen some POSIX tools take
with Macintosh metadata (e.g. filename/.resourcefork) is quite
similar.
Or ._filename, in Tiger's case, but yeah - you've always got the non-
EA-aware filesystem interop case to deal with. Dealing with
serialization/deserialization with different source/destination
filesystems can be amusing too.
Hmm. Actually you are correct: no standard tools support these
various approaches. Filesystem architects have long grappled with
this stuff, but no one has made user-space work well.
And, just for the record, I'm not arguing that we did either. When I
said we were at the "end of the spear" before (a phrase that Rob took
some objection to), I wasn't trying to suggest that we had absolutely
solved everything the right way - a lot of our command-line strategy
was driven more by expediency ("Oh crap, we have EAs in HFS now - we
need to quickly figure out how to preserve them in some number of
common cases").
Just to lay the problem out for everyone else, you have to at least
assume the following when analyzing approaches in this space:
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.
For us, that meant making sure that all the basic file primitives
(cp, rm, mv, etc) did the right thing for a file / file pair (again,
see #1) as an obvious first step, but transport requirements also
meant modifying rsync, scp, tar, pax, cpio, etc so that all of this
would also work over the network or in archival scenarios. Then we
remembered that editors like vim and emacs did temporary file
gymnastics in order to accomplish edits on files and that merely
editing a file wouldn't be expected by most people to result in a
loss of all its EA information, so those utilities had to be taught
to transfer the EAs over and that's just two utilities which do that
- there are more, including 3rd party editing tools, which are quite
likely going to cause EA data loss until they start employing the
same strategies.
It's all just a bit messy, which is probably why nobody's even wanted
to touch user space. They just do the filesystem support, declare
victory and run away. :-)
- Jordan
_______________________________________________
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