On Wed, 10 Mar 2004, D Andrew Reynhout wrote: > > On HFS+, a resource fork for <filename> is accessed via > <filename>/..namedfork/rsrc . Obviously, we can't send the > same filename to the destination, because an inode can't be > a regular file and a directory simultaneously. > > Map: <filename>/..namedfork/rsrc > to: <filename>.~~~namedfork.rsrc > There are chflags and finder metadata to be mindful of as well.
On your website, you state: "There are a few ways to approach the problem. RsyncX and rsync_hfs (by Kevin Boyd) turn the files into one of the single-fork formats of olde (e.g.: macbinary, applesingle, etc) and transfer them that way, then unwrap them on the other side. This method requires a HFS+ filesystem on the both sides, so it didn't suit my needs." This is untrue. rsync_hfs does not encode or split the file at all, it does a read in place. rsync_hfs with the --eahfs flag requires rsync_hfs on the other end because it has to catch all of the extra unencoded data that it throws. For --eahfs, what needs to be implemented is catching extra data on non-HFS+ filesystems, say storing them in a standard Apple alien FS format. If you change the file (encode split, etc), you are altering the source folders, which is not desirable. You could encode the files and trick rsync into using applesingle files, but that would incur a space and encode time penalty. You could encode (or split) files into appledouble format, which would incur less of a time and space penalty, but would still require additional space on the source machine. Both of these options do require a lot of 'tricking' rsync into thinking it is processing one set of files instead of another. I've considered taking the penalty for appledouble, storing the created metadata resource files in a temporary, non-source tree location (like /tmp/), given the demand for cross-platform storage. I'd say most people would prefer the source to be untouched, and let the destination create the appropriate repository for additional data (encode metadata and resource fork in memory at source, perform rsync algo with dest, and then send what is needed.) The agreed (and best) thought would be for SUS accepted format EA and ACL support in rsync, and for HFS+ patches for EA and ACL support a la: http://acl.bestbits.at/ to support other filesystems. Kevin Boyd OS X Deployment Coordinator Sys Adm UMIT Contract Services -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
