Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 Description of problem: I have vfat partition mounted under /dos. Here is what happens when I work on it (NFS is not running at all, nor enything is exported): ice/dos$ mkdir kasa ice/dos$ cd kasa/ icekasa$ mv ../deploy.zip . icekasa$ unzip de <TAB> unreadable ice kasa$ ls ls: .: Stale NFS file handle ice kasa$ cd .. ice/dos$ cd kasa/ ice kasa$ ls deploy.zip Here is partition table: Device Boot Start End Blocks Id System /dev/hda1 * 1 678 5125648+ b Win95 FAT32 /dev/hda2 679 692 105840 83 Linux /dev/hda3 693 779 657720 82 Linux swap /dev/hda4 780 2584 13645800 f Win95 Ext'd (LBA) /dev/hda5 780 2584 13645768+ 83 Linux icekasa$ cat /proc/mounts rootfs / rootfs rw 0 0 /dev/root / ext3 rw 0 0 /proc /proc proc rw 0 0 usbdevfs /proc/bus/usb usbdevfs rw 0 0 /dev/hda2 /boot ext3 rw 0 0 none /dev/pts devpts rw 0 0 none /dev/shm tmpfs rw 0 0 /dev/hda1 /dos vfat rw 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0 Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.ice/dos$ mkdir kasa ice/dos$ cd kasa/ icekasa$ mv ../deploy.zip . icekasa$ unzip de <TAB> unreadable 2. 3. Actual Results: ice/dos$ mkdir kasa ice/dos$ cd kasa/ icekasa$ mv ../deploy.zip . icekasa$ unzip de <TAB> unreadable Expected Results: ice/dos$ mkdir kasa ice/dos$ cd kasa/ icekasa$ mv ../deploy.zip . icekasa$ unzip de <TAB> should show what is in dir Additional info:
I have also seen this. I did not see this problem with RH8.0 and the original kernel version. I started seeing this issue only after running up2date and getting later Red Hat kernel releases for 8.0.
Additional note -- this is probably the same bug as in Bugzilla entry 83779
*** Bug 83779 has been marked as a duplicate of this bug. ***
I'm seeing this bug on redhat 9.0 too while accessing a FAT32 partition created with mkfs.vfat
VFAT doesnt have stable inode numbering that is needed for NFS.
If you were paying attention, you would see that this has nothing to do with NFS. The FAT32 partitions in question are not being NFS served or received. NFS may or may not even be running on the machines in question. That is why this is a bug and why this is a strange error. I suspect that later kernel updates to 9.0 may have fixed this as I haven't seen it again. But if I do see it again I will open a new bug and point out the fact that on my machine where I saw this I DO NOT HAVE NFS RUNNING.
Yup, same here. I have this problem and I don't have NFS running.
Yes I missed that. ESTALE can only occur over NFS ... at least in theory. Practice seems to be bizarrely different here
fs/namei.c: link_path_walk(), d->op->d_revalidate fails. vfat_revalidate checks the dentry->d_time matches the version of the parent. The mv moved the parent but seems not to have invalidated the dentry in any way. vfat_rename fails to change dentry->d_time or drop the dentry.
In bug, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=83779 which is marked as a duplicate of this one, there was no mv command. Could this one and that one have the same root problem anyway?
I think so.
Testing a fix
Closing - works in Fedora Core 2