As you all know, rsync doesn't have any special handling
for Mac OS X HFS+ resource forks. Kevin Boyd made RsyncX
and rsync_hfs, to address this gap, but they only work when
the destination filesystem is also HFS+. I haven't been
able to find any references to an rsync that is capable of
syncin
On Wed, Mar 10, 2004 at 01:57:41PM -0500, Kevin Alexander Boyd wrote:
> There are chflags and finder metadata to be mindful of as well.
Yes. I forgot to mention it, but for the moment, I'm accepting
the loss of creator/type, icon, etc. For now, all of that requires
manual repair upon restoration
On Fri, Mar 12, 2004 at 09:41:03AM -0500, Wesley D Craig wrote:
> I'd be happy to work on this myself, since I already have very similar
> code, if there was some possibility that the rsync maintainers would be
> willing to accept the modifications. Otherwise, it seems like a waste
> of effort.
On Fri, Mar 12, 2004 at 12:04:36PM -0500, Wesley D Craig wrote:
> My preference is to not adjust the protocol, at least not for HFS+
> support. I don't think it's necessary or particularly desirable. In
> particular, I don't see much value in making rsync changes that destroy
> my ability to s
On Fri, Mar 12, 2004 at 01:08:52PM -0500, D Andrew Reynhout wrote:
> If you convert the file to a single stream (AppleSingle), you
> have to change the filename on the destination, else you run the
Another problem with file conversion in-stream is what to do
with the converted file on the
On Sat, Mar 13, 2004 at 01:23:31PM -0800, Wayne Davison wrote:
> (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
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
Hi.
Several months ago, I posted my first pass at a patch to transfer
Mac OS X HFS+ metadata (resource forks and Finder metadata) to
non-HFS+ filesystems (Linux, Solaris, etc).
I finally got a chance to update the patch to reflect suggestions
offered on the list. Thanks for the ideas, this vers
Yes, I'm working on a proper AppleDouble format next.
It requires a combination of the two file handling procedures I've
added so far, which either: a) send a file under a newly composed
filename, or b) synthesize a "faux file" from filesystem metadata,
and send that under a composed filename, bu
If your files are on the Linux fileserver and accessed by the OSX
clients via Netatalk, then resource forks and Finder metadata are
already being stored in a format that rsync understands. Just run
rsync as usual.
If you were running HFS+ on the Linux box (hey, why not?), *then*
you'd need to do
Hi.
I've written a patch for rsync that will recognize Mac OS X
HFS+ resource forks and metadata, and transfer them to a
remote non-HFS+ filesystem.
The resource forks and metadata are stored in an AppleDouble
file, using the ._ naming scheme.
A few people have been helping me test the new versi
11 matches
Mail list logo
