> On Tue, Mar 24, 2009 at 2:51 PM, ropers <[email protected]> wrote: >> So what you're saying is that the exact same command first didn't work >> as expected, then worked, and then again didn't work, all within the >> very same directory? >> >> I find that very hard to believe. >> >> Was what you posted really an unedited transcript?
2009/3/24 Amarendra Godbole <[email protected]>: > > Yes, unedited. I did some more experimentation, and it appears that > find gets confused on ntfs if the path contains a space. This does not > happen on the native filesystem (ffs), even if the path contains a > space. Here is another example: > > ------------------------------------------------ > OpenBSD_45$ df -h /mnt/m0 > Filesystem Size Used Avail Capacity Mounted on > /dev/sd0i 19.5G 18.1G 1.4G 93% /mnt/m0 > OpenBSD_45$ pwd > /mnt/m0 > OpenBSD_45$ cd Intel/ > OpenBSD_45$ ls Logs > OpenBSD_45$ cd Logs/ > OpenBSD_45$ ls IntelGFX.log > OpenBSD_45$ pwd > /mnt/m0/Intel/Logs > OpenBSD_45$ cd ../../ > OpenBSD_45$ pwd > /mnt/m0 > OpenBSD_45$ find . -name "Intel*.log" > ./Intel/Logs/IntelGFX.log The above would seem to show that these problems don't just concern find(1), seeing that ls(1) also fails to show a file that appears to exist. Also, the above path does not appear to contain a space, so you can throw that theory out the window. > OpenBSD_45$ cd Program\ Files/Java/ > OpenBSD_45$ ls > j2re1.4.2_04 jre1.6.0_07 jre6 > OpenBSD_45$ pwd > /mnt/m0/Program Files/Java > OpenBSD_45$ cd ../ > OpenBSD_45$ find . -name jre6 > OpenBSD_45$ cd Java/ > OpenBSD_45$ find . -name jre6 > ./jre6 > OpenBSD_45$ cd ../ > OpenBSD_45$ pwd > /mnt/m0/Program Files > OpenBSD_45$ find . -name jre6 > OpenBSD_45$ find . -name jre6 > OpenBSD_45$ find . -name jre6 > OpenBSD_45$ find . -name jre6 > OpenBSD_45$ find . -name jre6 > OpenBSD_45$ cd Java/ > OpenBSD_45$ find . -name jre6 > ./jre6 > OpenBSD_45$ find . -name jre6 > ./jre6 > OpenBSD_45$ find . -name jre6 > ./jre6 > OpenBSD_45$ cd ../ > OpenBSD_45$ pwd > /mnt/m0/Program Files > OpenBSD_45$ find . -name jre6 > OpenBSD_45$ find . -name jre6 > OpenBSD_45$ find . -name jre6 > OpenBSD_45$ find . -name jre6 > OpenBSD_45$ find . -name jre6 > OpenBSD_45$ For identical commands to return different results (even when executed within the same directory, as shown in your previous transcripts) is very unusual. If this were me, then I would probably: - post a dmesg, - do a 24hr burn-in memtest using a known good boot CD (ie. whose md5/sha1 hashes still are what they should be), - scandisk/chkdsk the NTFS partition using another OS, preferably natively, using a recent Windows version, - do a badblocks -svn of the entire hard drive device this happens with -- but do a complete backup beforehand (badblocks(8) is filesystem-agnostic btw, even though it's found in e2fsprogs; cf. http://www.openbsd.org/4.4_packages/i386/e2fsprogs-1.27p5.tgz-contents.html , http://en.wikipedia.org/wiki/E2fsprogs ), - check if I can reproduce the same kind of behaviour with another NTFS partition on another hard drive, - check if I can reproduce the same kind of behaviour with another NTFS partition on the same hard drive, - check if I can reproduce the same kind of behaviour with another NTFS partition on another computer, !!! And of course you your kernel and userland aren't out of sync, right, RIGHT?! ;-) You could also install a more recent snapshot and see if the problem is still there. But maybe someone else on this list actually runs -current on a machine that also has an NTFS partition, and can see if they can reproduce this (I expect they won't be able to, otherwise we'd have heard much more about this issue by now). regards, --ropers
