On Sun, Mar 14, 2004 at 01:01:18PM -0500, D Andrew Reynhout wrote:
> I don't think there's any room left in the unsigned char to hold
> another flag, but if a protocol rev is necessary, widening the flag
> bits is much more flexible than explicit file-ids.
The flags bits have already been widened.
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
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, 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
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 us
On Fri, Mar 12, 2004 at 11:17:43AM -0500, D Andrew Reynhout wrote:
> The most straightforward and plausible idea I can think of
> is to update the protocol to include explicit file-IDs
> (instead of implicit offsets in the sorted flist)
I have no desire to see the current protocol get explicit IDs
On 13 Mar 2004, at 08:10, Albert Lunde wrote:
I'd note that the mkisofs man page listed about a dozen different
formats used in various contexts to store Mac resource forks and
finder metadata in various contexts. I'd imagine the advent of MacOSX
(with UFS support) has narrowed the field of what op
I'd note that the mkisofs man page listed about a dozen different
formats used in various contexts to store Mac resource forks and
finder metadata in various contexts. I'd imagine the advent of MacOSX
(with UFS support) has narrowed the field of what options are common
somewhat, but it's an area wh
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 source s
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 12 Mar 2004, at 11:17, D Andrew Reynhout wrote:
I think the maintainers have to err on the side of caution
regarding changes to the application, and especially to the
protocol.
My preference is to not adjust the protocol, at least not for HFS+
support. I don't think it's necessary or particula
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 10 Mar 2004, at 13:57, Kevin Alexander Boyd wrote:
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 desira
On 10 Mar 2004, at 15:07, Kevin Alexander Boyd wrote:
Every HFS+ file has finder metadata, and it must be stored somewhere in
order for the files to be correctly synced and/or restored.
Every HFS+ file may have Finder info. Most do not. That doesn't
really help, tho, since some do all must be ch
On Wed, 10 Mar 2004, Wayne Davison <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 10, 2004 at 01:11:35PM -0500, D Andrew Reynhout wrote:
>> but I'm less clear on
>> why (it appears) that *both* sides sort the flist.
>
> This is because the flist gets sent as it is created, so it is sent
> unsorted. Wit
On Wed, Mar 10, 2004 at 01:11:35PM -0500, D Andrew Reynhout wrote:
> but I'm less clear on
> why (it appears) that *both* sides sort the flist.
This is because the flist gets sent as it is created, so it is sent
unsorted. Without this rule it would be necessary to wait until the
list had been ful
On Wed, 10 Mar 2004, D Andrew Reynhout wrote:
>
> 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. I would have tried to shoehorn it
> in, but I haven't thought of a way to do it
I use rsync to distribute files from a non-OS X server to
OS X clients. I think using ._ files would clearly be the
best solution for the non-OS X side if you can get the
sorting issue worked out. That way the files on the non-HFS+
side of the rsync could be accessed directly by the Mac if
mounte
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 Wed, 10 Mar 2004, D Andrew Reynhout wrote:
>
> On HFS+, a resource fork for is accessed via
> /..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: /..namedfork/rsrc
> to: .~~
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
21 matches
Mail list logo
