Christopher Gorski <[EMAIL PROTECTED]> wrote:
> >>> can you try
> >>>
> >>> $(cd pond/photos; tar cf - *) | (cd /pond/copytestsame; tar xf -)
> >
> > CG> I tried it, and it worked. The new tree is an exact copy of the old
> > one.
> >
> > could you run your cp as 'truss -t open -o /tmp/cp.truss cp * ....'
> >
> > and then see if you can see all files being open for reads and check
> > if they were successfully opened for writes?
> >
>
> I ran:
>
> #truss -t open -o /tmp/cp.truss cp -pr * /pond/copytestsame/
>
> Same result as with cp. The same files are missing in the new tree.
>
> "unsorted/photosbackup/laptopd600/[D]/cag2b/eujpg/103-0398_IMG.JPG" is a
> file that is always missing in the new tree.
...
> The missing file does not seem to be in the truss output.
Do not expect to see anything useful when tracing open.
But check getdents(2).... i.e. what gets called from readdir(3).
I recently got a star bug report from a FreeBSD guy that turned
out to be a result from a missing ".." entry in a zfs snapshot
root dir.
Check the source of the failing program also...
I did recently spend a lot of time in fixing nasty bugs in the SCCS
source and it turned out that there have been places where the author
believed that "." and ".." are always returned by readdir(3) and that
they are always returned first.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
