Hello Paul, thanks for the fast response …
Paul Slootman <p...@debian.org> (Mon Sep 5 12:30:09 2011):
> severity 640492 normal
> tags +wontfix
> merge 640492 160982
> thanks
>
> On Mon 05 Sep 2011, Heiko Schlittermann wrote:
>
> > When I call
> >
> > rsync z a b c dest/
> >
> > rsync re-orders die filelist and transfers in alphabetical order.
> > This breaks some remote applications, in case they expect the files
> > appearing in some specific order. (debian reprepro + inoticoming as one
> > exampl).
>
> Filesystems don't guarantee that files will be written into the
> directory in order of writing.
I'd agree with you, as soon as rsync supports parallelity in sending the
files. But as long as the sender and the receiver transfer files in a
sequential order, I'd expect that these files appear in exactly that
(timely) order in the destination.
> Additionally, rsync first transfers to a
> temp file and renames when done, so anything that is watching a
> directory will see multiple events happening anyway.
In our example, inoticoming waits for the advent(?) of a *.changes file,
ignoring all other events. In case rsync uses a temp file, the
appearance of the *.changes file is even atomical. (Rsync does not need
to use temp file, --inplace modifies the destination file itself.)
> > And I believe, this behaviour breaks that what a unix user would expect.
>
> I'm a unix user since 1984, and I've learnt to test things to understand
> how they work :) Also rsync does work (more or less) on more than just
> unix-like systems, so that's hardly an argument.
Ok, thus you have about 6 years more unix exerience ☺. For me testing
is not a good base for understanding, reading the docs should be the
first part. (comes into my mind: at least this behaviour of rsync should
be documented...)
And I insist on calling this "unexpected". rsync does a great job in
replacing {,s}cp, but both tools do *not* re-order the files.
> In this case rsync orders the files to be sent as that is appropriate
> for the algorithm that is used to update the destination. In this
> special case that wouldn't strictly be necessary, but catering for such
> special cases would make rsync slower for the vast majority of use
> cases.
I can't reply here, since I didn't check the source.
I'd agree for all cases, where rsync gets passed wildcards (not talking
about passing the wildcards to the invoking shell).
> A simple workaround is of course to transfer the out of order files in
> separate rsync runs. In your example: first do z, then do the rest.
> As a workaround is trivially made, I cannot see how this could be
This workaround causes one more prompting for the passphrase (in case no
ssh-agend is used).
> classified as an important bug; especially since this behaviour has been
> around since the beginnings of rsync. Hence I'm changing the severity to
> "normal". Additionally, it's basically the same issue as described in
> bug report 160982 ("rsync alphabetizes files") , so I'm merging these
> bug reports, and marking it wontfix: I cannot imagine that rsync will be
> changed ever to not sort the file list.
Sorry for not finding the similiar issues. And I'll contact the rsync
mailing list, probably they can convince me about that.
Should I file a bug report about a missing note in the manpage?
Greetings from Dresden,
--
Heiko
signature.asc
Description: Digital signature
