In article <[email protected]>, [email protected] (Cathey, Jim) wrote:
> *From:* "Cathey, Jim" <[email protected]> > *To:* <[email protected]> > *CC:* [email protected] > *Date:* Fri, 28 Jan 2011 17:31:38 -0800 > > >I've worked out that while the code uses full paths to move the > files > >about, it uses relative paths in the zip command. > > > >so that's 2000 * 50 in the absolute worst case. > > > >It would be nice to know what length of command might break > busybox, > but > >failing that I'll stick an xargs in the command line and pray > loudly > :-) > > There's _two_ places that can croak: busybox, and > the kernel's argument buffer. Xargs is supposed to > keep it to a manageable level so far as the kernel is > concerned, it's up to busybox (and any other shell) > to handle that system-defined size. > > For any kind of a system script that can't know what it > can reasonably expect to see (i.e. worst case scenarios) > you should never use shell globbing, but rather find > and xargs. They will never fail. > > e.g. What does "rm -f /tmp/*" do if there are 12,000,000 > files in the /tmp directory? (Hint: nothing good!) > Whereas "find /tmp -mindepth 1 -maxdepth 1 ! -type d -print0 \ > | xargs -r0 rm -f" will succeed. More > complicated, to be sure, but more robust. Jim - I'm quite interested in this issue - a customer has just forced us to up the spec on our data logger so it may have to delete 1000+ files at once from a log area. I guess that will have the possibility to run into this issue. I've just done a pile of googling and now vaguely understand that line! is the -r0 a typo? David > > -- Jim > > > > > _______________________________________________ > busybox mailing list > [email protected] > http://lists.busybox.net/mailman/listinfo/busybox > _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
