GNOME Bugzilla – Bug 148297
copy ramfs mounts fails: No space left on device
Last modified: 2008-08-20 16:37:50 UTC
ceda@wendt:~$ su - Password: root@wendt:~# cd / root@wendt:/# mount -t ramfs none /mnt/ root@wendt:/# ls /mnt/ root@wendt:/# gnomevfs-copy file:///etc/hosts file:///mnt/ Failed to copy file:///etc/hosts to file:///mnt/ Reason: File exists root@wendt:/# mkdir /mnt/directory root@wendt:/# gnomevfs-copy file:///etc/hosts file:///mnt/directory/ Failed to copy file:///etc/hosts to file:///mnt/directory/ Reason: No space left on device root@wendt:/# Using Linux 2.6.7 and packages from debian unstable: Package: libgnomevfs2-0 Source: gnome-vfs2 Version: 2.6.1.1-5 No workaround => Normal ramfs probably rarely used => Normal
statvfs on a ramfs filesystem returns 0 as the number of free blocks. We probably need to special-case that in gnome_vfs_get_volume_free_space in gnome-vfs-utils.c
Created attachment 30561 [details] [review] fixer.
This fixes the problem by expanding the scope done by the NCPFS case (where free space information is not always available) From the Linux kernel source (linux/fs/ncpfs/inode.c): buf->f_type = NCP_SUPER_MAGIC; buf->f_bsize = NCP_BLOCK_SIZE; buf->f_blocks = 0; buf->f_bfree = 0; buf->f_bavail = 0; buf->f_namelen = 12; return 0; This is for the case that we previously caught with a special-case by examining f_bfree f_bavail and f_type. I replaced this check with a more general check for f_blocks==0 (which will still work with NCPFS) that will catch *any* filesystem that reports a total size of 0. The weird cases like /proc and devfs are (as previously) handled properly by the failure to create a ".vfs-write.tmp" file (devfs gives EACCES and procfs gives ENOENT) even when running as root.
Created attachment 32913 [details] [review] Updated patch that applies cleanly against CVS again. I'm fairly sure f_blocks is safe to use as I am using it. f_blocks is a valid structure member on at least these platforms (I was unable to find a platform on which it is not): statfs and statvfs on linux statfs on freebsd (no statvfs here) statvfs on solaris (no statfs here) statfs and statvfs on aix statfs on darwin (no statvfs here) Can I commit this one?
Please do, even though this doesn't fix the strange thing with the first gnomevfs-copy command reporting "File exists"?
alex?
Fredrik: this is because you literally tried to copy /etc/hosts to be named /mnt. gnomevfs-copy doesn't automatically add the name (ie: /mnt/hosts). I have another bug open about this somewhere.
Ryan: Ah, sorry about that (copy with last arg being a directory). I tried to apply the patch today against the source I get from debian unstable (gnome-vfs-1.0.5), but it fails and I can't see where in the file the changes should go. (The comment starting with CF etc is all gone in the version I have.)
the package in debian is gnome-vfs2 which is 2.8.4
Please note the the current patch got invalidated by the patch from Bug #302202
Will someone please approve this patch before I make it and it bitrots for the 3rd time? Otherwise I just won't bother.
Sorry for the delay Ryan. Maybe you could submit your patch to the gnome-vfs mailing list [1] for review? I'm not sure whether the zero block size check is enough to determine whether the file system does not contain any size information. Maybe we could/should do something similar as we do for NCP atm, i.e. keep around a list of file systems that don't provide this info and return NOT_SUPPORTED if the FS matches one of these types. [1] http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
Bug 326441 provides attachment 62896 [details] which outputs FS type: 858458f6 block size: 4096 data blocks: 0 free data blocks: 0 avail. user data blocks: 0 file nodes: 0 free file nodes: 0 f_namelen: 255 for my locally mounted example ramfs (i.e. none on /mnt type ramfs (rw)).