Paul Eggert wrote:
> I installed this
> patch into CVS coreutils. I don't think it'll fix the problem in
> general, but does it fix your particular problem?
Thanks. The patch does have the effect that, in my case,
[EMAIL PROTECTED]:/smb/ibook/data/temp $ df .
calls
statfs(".", {f_type="SMB_SUPER_MAGIC", f_bsize=4096, f_blocks=3456896,
f_bfree=253440, f_files=0, f_ffree=0, f_namelen=1024}) = 0
where it earlier called
statfs("/smb/ibook", {f_type="SMB_SUPER_MAGIC", f_bsize=4096,
f_blocks=3456896, f_bfree=253440, f_files=0, f_ffree=0, f_namelen=1024}) = 0
But the result in terms of blocks is still, unfortunately, the same.
From the Linux-2.4.21 and Linux-2.6.12.5 sources, it appears to be a
limitation in the Linux kernel. fs/open.c:
asmlinkage long sys_statfs(const char * path, struct statfs * buf)
{
struct nameidata nd;
int error;
error = user_path_walk(path, &nd);
if (!error) {
struct statfs tmp;
error = vfs_statfs(nd.dentry->d_inode->i_sb, &tmp);
if (!error && copy_to_user(buf, &tmp, sizeof(struct statfs)))
error = -EFAULT;
path_release(&nd);
}
return error;
}
As you can see, the original path is not passed to vfs_statfs(),
only the inode's superblock on the client (representing the mount or
mountpoint on the client) is.
Bruno
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
