|Summary:||(FS VFAT)Strange error (Stale NFS file handle) using VFAT partition|
|Product:||[Retired] Red Hat Linux||Reporter:||Dusan Djordjevic <dj.dule>|
|Component:||kernel||Assignee:||Arjan van de Ven <arjanv>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Brian Brock <bbrock>|
|Version:||8.0||CC:||alan, eddie.kuns, emile, scotto|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-05-21 20:10:08 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Dusan Djordjevic 2002-12-17 13:38:20 UTC
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:
Comment 1 Edward Kuns 2003-04-01 02:30:09 UTC
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.
Comment 2 Edward Kuns 2003-04-01 02:37:51 UTC
Additional note -- this is probably the same bug as in Bugzilla entry 83779
Comment 3 Alexander Larsson 2003-04-01 12:30:57 UTC
*** Bug 83779 has been marked as a duplicate of this bug. ***
Comment 4 emile 2003-05-13 15:05:08 UTC
I'm seeing this bug on redhat 9.0 too while accessing a FAT32 partition created with mkfs.vfat
Comment 5 Alan Cox 2003-06-08 15:29:56 UTC
VFAT doesnt have stable inode numbering that is needed for NFS.
Comment 6 Edward Kuns 2003-06-08 15:38:38 UTC
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.
Comment 7 Scott Otterson 2003-06-08 18:37:25 UTC
Yup, same here. I have this problem and I don't have NFS running.
Comment 8 Alan Cox 2003-06-08 19:00:41 UTC
Yes I missed that. ESTALE can only occur over NFS ... at least in theory. Practice seems to be bizarrely different here
Comment 9 Alan Cox 2003-06-08 19:07:10 UTC
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.
Comment 10 Scott Otterson 2003-06-08 22:07:56 UTC
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?
Comment 11 Alan Cox 2003-06-08 23:07:42 UTC
I think so.
Comment 12 Alan Cox 2003-06-27 21:53:15 UTC
Testing a fix
Comment 13 Alan Cox 2004-05-21 20:10:08 UTC
Closing - works in Fedora Core 2