Hello Miklos Szeredi, I am developing aufs, and Tomas M forwarded me your mail. Although I don't know where you have ever read aufs, it calls VFS path_lookup() and checks the gotten nd.dentry->d_inode members. Do you mean vfs_getattr() or something should be called after path_lookup(), and accessing inode members without vfs_getattr() is wrong? If it is true, current linux lookup routines are totally broken since they check inode.i_mode so often without vfs_getattr(). It must not be true.
What I am understading is, - Tomas's fuse-based filesystem doesn't initialize its root inode before and after fuse_main(). - the filesystem defines fuse_operations.getattr() and cusomizes inode members. - getattr() is not called at lookup. So the stat(2)-ed inode member differs from just lookup()-ed inode's. Also I had suggested to Tomas to try fuse_lowlevel_ops.lookup instead of fuse_operations and initialize its root inode. How do you think about it? Junjiro Okajima Tomas M: > I was speaking with FUSE developer and he thinks aufs should be modified > a bit. Here is the important part for aufs: > > > Subject: Re: [fuse-devel] fuse - uninitialized root inode > > Date: Wed, 18 Jul 2007 17:04:45 +0200 > > From: Miklos Szeredi <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > > > > Everything is correct if I execute 'stat /fuse-mountpoint' prior the > > > aufs mount. > > > > Because stat() calls the filesystem's ->getattr() method, which > > refreshes the attributes. > > > > Fuse assumes that ->getattr() is called before the file attributes are > > used, and aufs is breaking this assumption. > > > > Which I think is a bug in aufs, as it could break on _other_ > > filesystems which define ->getattr() as well. > > > > Miklos ------------------------------------------------------------------------- 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/
