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.
:-)
Jeff
"Jeff V. Merkey" wrote:
>
> I use write_inode() instead of notify_change() to set permissions in the
> vfs. According to /usr/src/linux/Documentation/filesystems/vfs.txt, if
> a file system driver does not implement notify_change(), the vfs will
> default the call to write_inode().
>
> I am seeing a case on 2.2.16 where chmod 444 * does not propogate the
> inode call to write_inode() in some cases. If someone uses
> write_inode() instead of notify_change() in their vfs implementation,
> could there be a case where chmod won't make it as a write_inode() call
> into the file system driver. I never see a call to write inode in
> certain cases, and the file attributes don't seem to get changed.
> h
> :-)
>
> 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/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:22 EST