some clarity Re: HFS+ resource forks: WIP patch included

[Kevin Alexander Boyd]

On Sat, 13 Mar 2004, Wayne Davison wrote:
>
> I have no desire to see the current protocol get explicit IDs.  I think
> it would be better to simply ensure that the lists sort identically on
> each side, and the best way to do that is to ensure that both sides sort
> the exact same list.
>
I agree.

> For instance, in the prior example of munging the names using ".~~~" in
> place of "/..", I can think of two better solutions than having the
> lists differ on each side prior to the sort:
>
> (1) The sender would create the file list pre-munged (with a simpler
> naming scheme) but flagged in such a way that it would know that it had
> to tweak the name back into its unmunged form before opening it.  (This
> solution avoids needing a modified rsync on the receiving side.)
>
Or to solve the naming issue completely, rsync on an HFS+ volume could
generate a file list that represents the data as it should appear
losslessly on a UFS volume.  If the files are received by an HFS+ volume,
they could be stored in their native format, if this version of rsync is
present on both HFS+ volumes.  If the files are received by a UFS machine,
or a machine without this version of rsync installed, then the files will
be stored in the format Apple currently uses for UFS volumes.  This would
require on the fly encoding of HFS+ files to UFS, on the fly decoding of
UFS formatted HFS+ files back to native HFS+, and an flist comparison of
HFS+ volumes in UFS format.

> (2) The sender sends the list unmunged but flagged as "needing to be
> transformed".  Such entries would then be munged sometime after the
> sort.  (This solution has the disadvantage of requiring both sides to be
> upgraded, but it does do less munging, especially if the receiving side
> had native support for the resource-fork files.)
>
This is what occurs in rsync_hfs, which can be browsed via cvs at
www.opendarwin.org.

Kevin Boyd
OS X Deployment Coordinator
Sys Adm UMIT Contract Services