>>> 'ls -la' gives (note the size!)
>>> dr-x------  2 johan johan      0 2008-12-19 14:39 .gvfs
>> Strange. Even an empty directory needs to contain '.' and '..' entries (and
>> the link count 2 suggests that it does). How any file system would store that
>> in 0 bytes ... maybe in the inode? Mis-information from the NFS server? What
>> FS type is this (on the server)?
>>> 'sudo ls -la' gives
>>> d?????????  ? ?     ?          ?                ? .gvfs
>> I can't remember having seen that kind of 'ls' output, but a failure to 
>> stat()
>> /home/johan/.gvfs has more to do with the permissions on /home/johan than the
>> subdirectory. The results you get from mismatched 'r' and 'x' permissions on
>> directories tend to be confusing (being able to read a directory but not
>> access (and thus stat()) the files in it, or being able to access the files
>> but not read the directory).
> 
> adamg@adamg-laptop:~$ id
> uid=1000(adamg) gid=1000(adamg) groups=1000(adamg)
> adamg@adamg-laptop:~$ ls -ld .gvfs
> dr-x------ 2 adamg adamg 0 2008-12-17 10:19 .gvfs
> 
> It looks normal enough, except that 0 byte size...
> 
> adamg@adamg-laptop:~$ ls -la .gvfs
> total 3
> dr-x------  2 adamg adamg    0 2008-12-17 10:19 .
> drwxr-xr-x 76 adamg adamg 3296 2008-12-18 21:28 ..
> 
> It does indeed contain the two sub directories... as per usual..
> 
> adamg@adamg-laptop:~$ sudo bash
> root@adamg-laptop:~# id
> uid=0(root) gid=0(root) groups=0(root)
> root@adamg-laptop:~# cd /home/adamg
> root@adamg-laptop:~# ls -ld .gvfs
> ls: cannot access .gvfs: Permission denied
> root@adamg-laptop:~# ls -la .gvfs
> ls: cannot access .gvfs: Permission denied
> root@adamg-laptop:~# ls -l .gvfs
> ls: cannot access .gvfs: Permission denied
> 
> Nope, root doesn't seem to have access to it... just doesn't work
> 
> root@adamg-laptop:~# ls -ld
> drwxr-xr-x 76 adamg adamg 3296 2008-12-18 21:28 .
> 
> root does have permissions on the parent directory (/home/adamg)
> 
> root@adamg-laptop:~# mount
> /dev/sda3 on / type reiserfs (rw,notail)
> gvfs-fuse-daemon on /home/adamg/.gvfs type fuse.gvfs-fuse-daemon
> (rw,nosuid,nodev,user=adamg)
> 
> Just a normal reiserfs V3 file system... nothing special here...
> 
> However, the second line of output does tell us a lot more about what is
> going on :) It is a mountpoint, and what is inside is it's own FS....
> 

https://www.redhat.com/archives/fedora-list/2008-October/msg02762.html
Quoting Rick Stevens:

".gvfs is a virtual filesystem and doesn't follow normal filesystem
semantics (witness the fact the size of it is zero).  find can't
traverse it if you aren't the owner as the callbacks and such used when
referencing it only exist in the owner's Gnome instance.

Making a copy of it creates a real, honest-to-goodness directory with a
non-zero size, which find can happily traverse even if you aren't the
owner since it's a real file/directory, not a virtual one."

End of mystery :). I just excluded .gvfs/ to get rid of the error message.


 > So, probably better to pass --one-file-system to rsync rather than
 > worrying about trying to exclude /proc, /sys, etc...

But then we have to worry about mounts on each client separately to get 
it all backed up, right?

------------------------------------------------------------------------------
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/