Miklos Szeredi:
> > When you create/remove something, lookup operation involves accessing
> > inode->i_uid, i_gid, permission bits in i_mode, i_ino and i_flags.
> >
> > For example,
:::
> > - may_open() checks inode->i_uid.
>
> Yup.
>
> > - unlink(2) and rmdir(2) check the sticky bit and inode->i_uid.
>
> Yes, this is perhaps the most problematic one. I do have it on my
> todo list to move this into the filesystem specific permission
> checking.
:::
> > Are they all wrong too?
> > Or i_nlink is the exception?
>
> Yes, if a check uses an inode attribute without refreshing it with
> ->getattr() that check is wrong. And yes we do still have a couple of
> those checks in less often used places.
Your two YESs made me confused.
But I could understand that you are still asserting getattr is
necessary even in the cases of may_open() or something, and that is a
VFS lookup bug.
Am I right?
> What do you mean, just after fuse_main()? If the filesystem is not
To modify Tomas's fs like this,
{
- return fuse_main();
+ err = fuse_main();
+ if (!err)
+ err = stat(mount point);
}
And override fuse_lowlevel_ops.lookup to customize inode members for
other than root.
Junjiro Okajima
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
