some clarity Re: HFS+ resource forks: WIP patch included
D Andrew Reynhout
reynhout at quesera.com
Sun Mar 14 18:21:05 GMT 2004
On Sat, Mar 13, 2004 at 04:40:59PM -0500, Wesley D Craig wrote:
> 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.
There aren't sort-order vagaries, per se...the problems were
created by my approach to adding a file to the flist (adding the
source path, with new struct elements for the destination path.
Done that way, the source path (<filename>/..namedfork/rsrc) had
to sort into the same position as the destination path, which is
why I chose the awkward <filename>.~~~namedfork.rsrc replacement.
Anyway, I think I can avoid that problem now. I'll be working
on it.
> 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
> header.
Yeah, I built a few walls into my thinking about the problem
when I went down the above source/destination-path path. That's
why I posted my patch... This looks workable now, as does the
destination ._<filename> mapping.
> The question is, is something like this acceptable to the
> maintainers?
Indeed.
Thanks for the ideas, everyone.
Andrew
More information about the rsync
mailing list