2010/9/20 Jeff Layton <jlayton@xxxxxxxxx>: > On Sun, 19 Sep 2010 21:28:41 +0200 > Stef Bon <stefbon@xxxxxxxxx> wrote: > >> Hello, >> >> >> It's causing some unwanted behaviour. >> How can I change that, or is this not changeable? >> Stef > > I think it's just a matter of setting the inode->i_size on the > directory. I *think* that when you do a QPathInfo call to a directory > via cifs the size comes back 0. Setting this to something else probably > means an extra call to the server to get the "real" size (whatever that > means). The question is, what should this be set to? > > -- > Jeff Layton <jlayton@xxxxxxxxx> > Yes that's a good question. But a share mounted with cifs should behave like it is's just a local harddrive partition right? So these values are obligatory... In my construction - so I'm speaking only for my own here - it's also set the size (and the blocks) in the FUSE fs. Remember, I'm using the FUSE fs fuse-workspace as the one which is used, and the various mounts to resources like smb shares (mounted with cifs of course, managed with autofs) are the underlying backend. My FUSE can correct things, like this. I wonder, it can correct things, but is it also a must? My fuse fs takes these values just from the underlying fs, and this can result in a size of directories of 4096 when the underlying fs is a mounted partition (of for example an USB disk) and zero when it's a cifs mounted smb share. Is it a bad thing that these values differ in the same fs (in my case thus fuse-workspace)?? Maybe you know this, else I'll try at the fsdevel list. Stef -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
