https://bugzilla.samba.org/show_bug.cgi?id=3168
------- Additional Comments From [EMAIL PROTECTED] 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. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
