On Sun, Nov 25, 2007 at 09:18:33AM +0100, Jim Meyering wrote: > Justin Pryzby <[EMAIL PROTECTED]> wrote: > > It appears that fts uses some stat data which doesn't work as expected > > for fat32 filesystems. > > > ... > > Since the output changes on each invocation of the program, I'm of the > > impression this is a bug in the filesystem driver (an apparent result > > of generating data to fill the structure fields to appease the > > traditional system calls when the filesystem doesn't natively use > > those values). > > > > The same problem occurs even when the FS is remounted readonly, but > > disappears if the FTS_NOCHDIR option is set. Here's a diff fragment > > of strace -v demonstrating the d_ino field differing between > > invocations. > > Thanks for the report. > > You're right. This is a problem in your environment, not with du/fts. > If the driver changes the dev/inode of an open file, all bets are off. > > Why are you using FTS_NOCHDIR anyway? no openat support? It was just for debugging.
> What version of du are you using? 5.97-5.3 from debian etch. > For things like this, it's good to mention what kernel and libc > version you're using -- for reference if/when others encounter > the same problem later. linux-2.6.22-3-vserver-686, glibc-2.7-1 (although the problem was initially experienced with 2.6.X, I just reproduced it with this new version). However this time the problem occurred only on the first invocation. $ du -sh /mnt/1/music/jake/ du: `/mnt/1/music/jake/Music/Newly Ripped': No such file or directory du: `/mnt/1/music/jake/Music/Napster Directory': No such file or directory du: `/mnt/1/music/jake/New Folder': No such file or directory du: `/mnt/1/music/jake/Holiday CD 2006 takes': No such file or directory 177G /mnt/1/music/jake/ $ du -sh /mnt/1/music/jake/ 186G /mnt/1/music/jake/ I note that yesterday I added a 2nd 128MB ram chip to this machine. So my current hypothesis is that there's a hash table or such of inodes which was being overflowed. So this may just be an (expected?) consequence of accessing a large devices (with many files) on a machine with not much ram. Justin _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils