Skip Menu |

This queue is for tickets about the Brackup CPAN distribution.

Report information
The Basics
Id: 72526
Status: new
Priority: 0/
Queue: Brackup

Owner: Nobody in particular
Requestors: doubiman [...]

Bug Information
Severity: Normal
Broken in: 1.10
Fixed in: (no value)

Subject: Calling mode on undefined object (File::stat lazy load failure?)
Download (untitled) / with headers
text/plain 1.8k
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/ 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/ 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.

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to