Anne Milicia writes: > Hi Nikita, > The time when I see a problem is when an existing file in a directory is > deleted, and that freed objectid is reused when a new file is created in > the same directory. Then the file handles for both the deleted and > newly created files consist of the objectid's for the file and parent > directory's which are all the same. With the 3.5 version in 2.4, the > generation number field of the file handle is set to the parent > directory objectid which again is the same for the deleted and new > files. But, after conversion to 3.6, won't the new file created get the > new stat data and thus a unique generation number that will distinguish > the new file from the old file that was deleted?
Yes, you are right. The only case, where stale handle wouldn't be detected is unlikely situation when generation of newly converted inode coincides with objectid of parent directory of removed old format inode. > > With a 3.5 format filesystem I can open a file on 1 client system for > write, then on a different client system I can delete the first file and > create a new different file in the same directory which gets the exact > same file handle. Then, back on the first client system, as long as I > have write permission for the new file, I can write(2) to the new file > with my old file descriptor and corrupt the new file. I should get an > ESTALE error, but since the file handle is the same, the server finds > the new file via reiserfs_fh_to_dentry() and lets my client program > write to it. > > With a 3.6 format filesystem I properly get an ESTALE return on the > first client system when I try the same test. And indeed, I am working > with 2 different file handles for the 2 different files, distinguished > by the generation numbers. Once the version is converted to 3.6, I > think this problem is fixed. > > Thanks, > Anne > > Nikita Danilov wrote: > > > > Hans Reiser writes: > > > Thanks Anne, Nikita please put into faq that all NFS users should use > > > the 2.4 kernel with format converted to 3.6. > > > > -conv is not going to help here: old files still have old stat-data and > > no place to store generation counter. > > > > > > > > Hans > > Nikita. > >
