But since it's already been established that -exec + is cutting off and starting a new command line every 128 KiB or so, similar to xargs, that's clearly not the issue.
Hold on a second...
“128 KiB or so†now is it? Earlier you used
256 as some official size, in the midst of dismissing my comment about 150K as being above the threshold. And now we're saying that 128 is what's
“already been established†?
As far as
“that's clearly not the issue†goes, didn't you see what i wrote above??? Here... i'll repeat a line from my previous reply, in 11 point size:
at this point i presume my "alert the operator" guess was probably incorrect.
So why are you getting all worked up over something i've
already withdrawn? 
If this were designed to "alert the operator", then it would simply give an error such as "argument list too long" or something actually appropriate. This is not the case.
Yep... but since i conceded that point already (
twice in fact), your purpose in rehashing it is truly mysterious.
Instead of posting snotty comments like this, you could just think about it and realize the problem with -exec + is that it evidently DOESN'T WORK RIGHT, whereas xargs does. Given the choice between taking a fraction of a second longer and actually working versus failing slightly faster, I'd go with the one that works
Which part was snotty??? Seems like we're just trading shots here, whenever the other makes a slip.
>> DOESN'T WORK RIGHT
>> failing
Well, every example so far produces the right answer (despite the odd error message). Anyway, I totally followed the reasoning behind
xargs being a worthy alternative. (in fact,
xargs was long one of my favorite tools, and still is... so you're preaching to the choir there). My only objection was the way you initially
worded the case for
xargs, as it contained false (or misguided) reasoning. Now that you've revised the wording, i no longer object.
BTW (to all concerned), this "
fts_read: Cannot allocate memory" error is apparently something new in Snow Leopard. I've never seen it in Leopard (and i use
find a lot in my shell scripts, as well as on the command line).
At this point, I think that there is probably a random element involved, depending on the state of memory at the time the code is run (which is often the case with memory-related issues), -- I've actually issued the same command line multiple times, and gotten failures sometimes and not others.
Interesting...
that i have not seen, after hours of tinkering. So —if you can post a particular command which will behave that way —please do, as i would find that clue quite compelling.
I posted in this thread because artie505 asked for help; I did so by posting a C-based tool which should scan for HFS+ damaged files significantly faster and more accurately than using the find tool, as well as being more reliable due to the lack of reliance on possibly damaged shell tools.
Understood and already acknowledged. I replied simply with an enthusiastic "
Excellent!" — despite the fact that your post was couched with (subtle) criticisms of my efforts. I.e., yes, i already knew that IF we were to search
other areas, then resource-fork-only items would produce false hits. But we weren't asked to search other areas... so the need for such a system-wide tool wasn't a consideration at the time. BTW, why is your binary so big? 50K seems huge for something doing such a basic task. Care to post the source?
However, I'm starting to think it was a mistake to come here. If the thread's going to be about defending your "This error was designed to inform the operator about something that the tool automatically takes care of anyway, by reporting a completely different error" statement ad nauseum, then I'm out.
Begging your pardon, but you have mischaracterized the matter entirely.
- First off, my statement was never an assertion. You claim i said "was designed" -- but if you go back and read what i actually wrote, you'll see the phrase was "may be". So it never was anything to be defended. Your "mistake" was to dismiss it in such an offhanded manner, and then not supply anything useful to replace it which fit into the facts already seen: that there was no error in terms of items found. So you're the one who started the "nausea" here.
- Second, twice now you have ignored what i wrote... so here is part 2 (in a large font size for easy reading):
Having studied it further, i'll have to agree with you.
Thus: a) you started it, and b) you have pursued it (without reason). My subsequent posts have been engaged in studying that
fts error, not "defending" anything.
What hath
Artie wrought this time?
