Joerg Schilling wrote:
> "Will Murnane" <[EMAIL PROTECTED]> wrote:
>
>> On Jan 30, 2008 1:34 AM, Carson Gaspar <[EMAIL PROTECTED]> wrote:
>>> If this is Sun's cp, file a bug. It's failing to notice that it didn't
>>> provide a large enough buffer to getdents(), so it only got partial results.
>>>
>>> Of course, the getdents() API is rather unfortunate. It appears the only
>>> safe algorithm is:
>>>
>>> while ((r = getdents(...)) > 0) {
>>> /* process results */
>>> }
>>> if (r < 0) {
>>> /* handle error */
>>> }
>>>
>>> You _always_ have to call it at least twice to be sure you've gotten
>>> everything.
>> In OpenSolaris, cp uses (indirectly) readdir(), not raw getdents().
>> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libcmd/common/cp.c#487
>> which uses the build-a-linked-list code here:
>> http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/coreutils/coreutils-6.7/lib/fts.c#913
>> That code appears to error out and return incomplete results if a) the
>> filename is too long or b) an integer overflows. Christopher's
>> filenames are only 96 chars; could Unicode be involved somehow? b)
>> seems unlikely in the extreme. It still seems like a bug, but I don't
>> see where it is. I am only an egg ;-)
>
> An interesting thought....
>
> We of course need to know whether the user used /bin/cp or a "shadow
> implementation" from ksh93.
>
> I did never see any problems with star(1) and star(1)/libfind(3) are heavy
> readdir(3) users...
>
> Jörg
>
I am able to replicate the problem in bash using:
#truss -tall -vall -o /tmp/getdents.bin.cp.truss /bin/cp -pr
/pond/photos/* /pond/copytestsame/
So I'm assuming that's using /bin/cp
Also, from my _very limited_ investigation this morning, it seems that
#grep Err /tmp/getdents.bin.cp.truss | grep -v ENOENT | grep getdents
returns entries such as:
getdents64(0, 0xFEC92000, 8192) Err#9 EBADF
getdents64(0, 0xFEC92000, 8192) Err#9 EBADF
getdents64(0, 0xFEC92000, 8192) Err#9 EBADF
getdents64(0, 0xFEE34000, 8192) Err#9 EBADF
...(truncated)
whereas it seems like with a copy where everything is transferred
correctly that the above statement returns no getdents64() with an EBADF
error, leading me to believe that somewhere along the line getdents64 is
attempted to be called but that the descriptor is invalidated somehow.
Again...I am only gleaming that from a very limited test.
-Chris
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
