Bug 79842 - (FS VFAT)Strange error (Stale NFS file handle) using VFAT partition
(FS VFAT)Strange error (Stale NFS file handle) using VFAT partition
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
: 83779 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2002-12-17 08:38 EST by Dusan Djordjevic
Modified: 2007-04-18 12:49 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-05-21 16:10:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dusan Djordjevic 2002-12-17 08:38:20 EST
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>

ice kasa$ ls
ls: .: Stale NFS file handle
ice kasa$ cd ..
ice/dos$ cd kasa/
ice kasa$ ls

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:

Steps to Reproduce:
1.ice/dos$ mkdir kasa
ice/dos$ cd kasa/
icekasa$ mv ../deploy.zip .
icekasa$ unzip de <TAB>

Actual Results:  ice/dos$ mkdir kasa
ice/dos$ cd kasa/
icekasa$ mv ../deploy.zip .
icekasa$ unzip de <TAB>

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-03-31 21:30:09 EST
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-03-31 21:37:51 EST
Additional note -- this is probably the same bug as in Bugzilla entry 83779
Comment 3 Alexander Larsson 2003-04-01 07:30:57 EST
*** Bug 83779 has been marked as a duplicate of this bug. ***
Comment 4 emile 2003-05-13 11:05:08 EDT
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 11:29:56 EDT
VFAT doesnt have stable inode numbering that is needed for NFS.
Comment 6 Edward Kuns 2003-06-08 11:38:38 EDT
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 14:37:25 EDT
Yup, same here.  I have this problem and I don't have NFS running.
Comment 8 Alan Cox 2003-06-08 15:00:41 EDT
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 15:07:10 EDT
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 18:07:56 EDT
In bug,


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 19:07:42 EDT
I think so. 
Comment 12 Alan Cox 2003-06-27 17:53:15 EDT
Testing a fix
Comment 13 Alan Cox 2004-05-21 16:10:08 EDT
Closing - works in Fedora Core 2

Note You need to log in before you can comment on or make changes to this bug.