some clarity Re: HFS+ resource forks: WIP patch included
Wesley D Craig
wes at umich.edu
Sat Mar 13 21:40:59 GMT 2004
On 12 Mar 2004, at 13:08 (or thereabouts), D Andrew Reynhout wrote:
> If you split the file into multiple files (AppleDouble), you
> have to play games with the sort routine, or else you risk FS
> corruption. And it's very inconvenient to be certain that your
> sort trick had the desired results.
rsync uses qsort(3) after building the whole file list. At least
that's the case in rsync-2.6.0. See:
send_file_list() around line 1066 of flist.c
qsort is specified in the C89 standard. The compare function is passed
to this routine by rsync. So if there are sort-order vagaries, they
would represent a basic bug in rsync.
To fake up the second file, I might suggest a change either to
make_file() or in send_file_name(), right after make_file() is called.
> Unless you know a bit about
> the destination FS (specifically what ASCII vals are allowed in
> filenames), you might still get it wrong.
Again, I'm not aware that rsync supports ideas like file name
"munging". The issue you describe is general, not anything to do
specifically with supporting, e.g., AppleDouble.
> Another problem with file conversion in-stream is what to do
> with the converted file on the source system. You could store
> it as a tmp file somewhere, (bad, again creating the different
> filename/sort order problem which seems to require a protocol
> revision to solve) or you could hold it in memory (and possibly
> create enormous memory requirements) and then patch all of the
> functions that get file comparison info (size, ctime, mtime,
> checksum, etc) to deal with memory blocks (even worse, and you
> still create the same problem to safely put the new file into a
> different filename on the destination).
A tmp file would be "dirty". Assuming AppleDouble, the header portion
of the file is a fixed size, i.e., not enormous. The actual contents
of the resource fork can be treated like any other file. So the only
requirement is for the sender to handle the header specially and to
adjust byte offsets in the resource fork by the size of the fixed
> I'd love to be wrong about requiring a protocol rev. I just can't
> find an opportunity in the code. I'm still looking. :-)
The above sounds like a recipe to me. The question is, is something
like this acceptable to the maintainers?
More information about the rsync