| Subject: | Calling mode on undefined object (File::stat lazy load failure?) |
I ran brackup for my home directory and got the following output:
Discovering files in /home/doubi/...
Error running backup: Can't call method "mode" on an undefined value at
/usr/local/share/perl/5.10.1/Brackup/File.pm line 65.
The problematic file was './gvfs', part of 'the virtual filesystem for
the GNOME desktop, which allows users easy access to remote data via
SFTP, FTP, WebDAV, SMB, and local data via HAL integration, OBEX and
others' (wikipedia).
More detail
-----------
My naive exploration of the issue is as follows.
All Brackup::File objects have a stat property, which is a File::stat
object, and is created by originally by File::stat::lstat($path) on line
127 of Brackup/Root.pm.
By stepping through I saw that most (every?) Brackup::File has an
undefined stat property on entering Brackup::File::is_file. It seems the
File::stat object is instantiated on access, as most
S_ISREG($self->stat->mode) calls go off without a hitch. For ~/.gvfs
though, the stat object can't be created.
I should've seen this coming, as ~/.gvfs caused errors for my previous
self-rolled rsync backup script; rsync could move on from the error
though. I was also wrong-footed as the line
ignore = ^\.gvfs/
in my .brackup conf file failed to exclude the folder; I had to remove
the trailing slash.
Solutions?
----------
All in all, I'm not sure what should be done about this issue, mostly
because I'm not 100% sure about this weird lazy loading File::stat seems
to be doing.
It would be silly to have to verify File::stat instantiation in every
Brackup::File method. This should be checked somewhere beforehand.
On the other hand, perhaps this isn't currently done due to memory
considerations or something.
In any case, there can't be that may freaky virtual filesystem files
around, and now I've understood the trick of the ignore line (which /is/
tricky, as ~/.gvfs lists itself as a folder, not a file) life can go on.