Messages in this thread | | | Date | Thu, 27 Jul 2000 10:44:02 -0600 | From | "Jeff V. Merkey" <> | Subject | Re: Strange chmod behavior on 2.2.16 with write_inode() |
| |
Alexander Viro wrote: > > On Wed, 26 Jul 2000, Jeff V. Merkey wrote: > > > > > More on this problem -- here's someting weird. If I wait a few seconds > > after typing 'chmod 444 *' on a directory of files, then I start seeing > > write_inode() come through the vfs, however, if I do an 'ls -l' on the > > directory immediately after I issue a chmod command, then the > > write_inode() never seems to happen. It looks like write_inode() is > > getting called by some sort of delayed process (who writes dirty inodes > > back to disk). The changes don't show up changed right away after a > > chmod call either. > > > > I think I'll just implement notify_change() since the vfs.txt > > information about relying on notify_change() to default to write_inode() > > is obviously incorrect -- there's a hole somewhere where the inode > > permissions can get lost. > > Do you, by chance, do something with inodes in readdir()? I suspect that > it should be the right place to look. Looks like you are losing the dirty > bit on inode before it gets written...
No. I don't believe I do. Al, the codes at 207.109.151.240 -- DIR.C has readdir() and the dentry stuff. I might be doing something else flaky though.
> > Eh, wait. Where does your filesystem keep inode metadata? I think I know > one of the possible reasons, but I'ld like to hear the answer first...
The only inode meta-data I use is the inode->u.generic_ip pointer to hold the hash head for the fat chain header/semaphore. This structure gets assigned to the inode on read_inode() calls and zeroed when the put_inode() gets called.
Jeff
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |