[Bug 3168] --min-size cores in 2.6.5 and is completely missing in 2.6.6

[samba-bugs at samba.org]

https://bugzilla.samba.org/show_bug.cgi?id=3168





------- Additional Comments From foner-rsync-bugzilla at media.mit.edu  2005-10-14 11:48 -------
(In reply to comment #2)
> --min-size has never been released in a version of rsync except in the patchs
> dir.  I know that Debian has released several versions with --min-size included
> (and has recently switched over to using the official patch, which does NOT dump
> core), but there may be other distributions that may have decided to include the
> option.  This option is being considered for a future release, but seeing how
> you've compiled your own version, just apply the patch from the patches dir and
> enjoy.

Well, that explains it---Ubuntu Breezy (officially released yesterday, and thus
around for the next six months) picked up a (defective) Debian version of it. 
Unfortunately, this means that every Breezy user who tries this option will have
rsync core on them.  (Maybe Breezy will pick up a fixed Debian version, but that
actually doesn't help a lot---see below.)  Furthermore, many Breezy users will
not be nearly sophisticated enough to ask, "did Debian make an incompatible
change?"  Instead, they'll send bug reports.

I've compiled my own version, but not having this in the non-Debian version is
actually more of a big deal than you think (I think :).  For one thing, it means
I now have a quandry about -my- version.  Do I blow away the Ubuntu one?  Then
updates will blow mine away.  Do I nail the version so that doesn't happen? 
Then it becomes the one sore thumb that -won't- get updates, including security
updates.  Do I put it elsewhere instead?  Then I have to worry about it being in
the path of everything that uses it---including root, including random scripts,
etc etc.  It's a hassle and a waste of time---and risks being forgotten at an
inopportune moment.

Furthermore, since Debian has a version but rsync mainline doesn't, script
writers are in a total quandry, since there's this incompatible feature they
can't depend on being there.  Sure, that's the case for every new feature in
rsync, but it's particularly weird that max is there but min ain't.  It makes
writing scripts that say "put all the big files -here-, and all the little files
-here-" suddenly become a pain to write and/or maintain.

Plus, since even the Debian version has the fencepost issue, I have to kluge
around it.  And if you ever -do- release a version without it (either by parsing
+1 at the end, or by changing < in min-size to <= as I did), then scripts that
others have built based on the Debian one will be subtly wrong.  This seems an
enormous amount of pain and bookkeeping to handle a tiny change with, as far as
I can see, no impact on the rest of rsync if it isn't being used.  Not having it
added in April seems senseless (if it had been there then, Breezy would
certainly have it now, instead of an incompatible coredump), and seems doubly
senseless now.

I mean, it'd be one thing if it was a performance or stability issue, but it's
clearly not, especially since --max-size made it in.  (And no, saying "use find"
isn't the solution, either---some uses of rsync, e.g., dirvish, make that really
painful, again just to work around a tiny bit of non-orthogonality.)

> As for who needs to know about the option, the receiver is the one that
> implements the filtering logic for what files get transferred, so as long as
> you're pulling files, the sending rsync doesn't ever see options like
> --max-size, --update, --existing, etc.

Ah.  Good to know.  (But wouldn't it be somewhat more efficient to have the
sending rsync be able to apply filters if it can?  Less wire traffic and maybe
faster in the filesystem.)

> As for the size comparison boundry, one solution would be to allow any easy way
> to specify +1 or -1, such as --min-size=50k+1 or --max-size=50m-1.

That's a cute idea.  More work to code, but definitely cute.

> Yes, the man page should be improved to mention exactly what the suffixes mean
> -- thanks for pointing that out.  I'm also thinking about allowing the suffix to
> specify if the user wants a K to be 1000 instead of 1024, such as suffixing the
> K, M, or G with a T to indicate that a power of ten is desired.

I think the last thing we need is yet -another- incompatible way to say "human
or machine?"  I don't recall seeing T anywhere else to do this, but maybe some
popular piece of software does this and I haven't noticed.  (It's bad enough
that some accept only lowercase kmg and some accept only uppercase!)  du has
clearly been having these issues, having gone for -h and -H and then deprecating
one in favor of -si (yuck!) and who knows where that's gonna end.  Are there any
other utilities out there that seem popular and have settled this one way or the
other?  What do they do?  Do they use upper vs lower case to decide it? 
Something else?  (I honestly don't know, but I'm hoping somebody's thought about
this...)

Thanks.

P.S. Would it have made sense to have opened this directly on the mailing list
and not in the bug database?  I guess it would have gotten it wider discussion;
I can forward, or you can if you want, if you think it would help.




-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.