Register / Login | Desktop view |
This will certainly cause the archive to be invalid afterwards. QRecall was unable to finalize the archive. Any subsequent attempt to use it will require that you first repair it so that QRecall knows that its in a valid state before it begins.Ralph Strauch wrote:Wednesday evening I initiated a backup to an external WD hard drive. Qrecall ran for a couple of hours and then hung. I unsuccessfully attempted to rerun it and eventually realized that my USB port had failed and the external HD was no longer mounted, so that was the cause of the backup failure. (The USB failure must have been a driver failure, because after a restart the port is working again.)
You could have repaired the archive in situ. The default repair options are conservative so the "Copy recovered data to new archive" is on by default. But for most situations this isn't necessary. Unchecking that option will allow you to repair the archive without copying it first. I have a to-do item to leave that option unchecked by default in the next release.The archive was corrupted (header length invalid) and would not reindex. I didn't have enough free space to repair it, so I trashed it, started a new backup, and went to bed.
Failing to read or capture a source file should not (by itself) cause the capture to hang or the archive to be corrupted. More than likely something else (like what happened earlier) occurred while the localizable strings file was being captured. I doubt there's anything wrong with that file. Your log files ? which you are welcome to send to me ? should explain the root cause.In the morning I found that it had hung at 1am with a "Cannot capture localizable strings" error referring to a Japanese lprog file in a printer driver. I excluded that file from capture (though it had been previously captured without error) and tried again.
This would be consistent with an incomplete layer that was recovered during the repair (although I'm surprised the layer doesn't say "-damanged-" or "-incomplete-"). The size of the first layer is impossible to determine because it never finished.Again, I found that my archive was corrupted with a "header length invalid" error. This time I repaired the archive and recaptured, and everything seemed to work -- except for the layer information in my current archive. My current archive is 87gb, and shows that it contains two layers. Layer 1, which I think is the repaired version of my 44gb corrupted capture, shows and unknown time of capture and 0gb in size, while layer 2 shows the time of my latest capture and 52gb size, the same size shown for the capture in the log.
Reindexing won't help, because that information doesn't exist. The first capture never finished, so the summary statistics (capture date, number/size of captured items, etc.) was never generated or recorded.I tried reindexing the archive to see if this would correct the layer 1 info, and it doesn't.
Unlike a regular file system, a QRecall archive is a database of file information and data. Sizes get confusing, because multiple items can all share the same data. So capturing 30GB, 20GB, then 10GB won't produce a 60GB archive. The archive could be much smaller than that. In the extreme case where all of the files contains zeros, the archive could be less than a megabyte.So I think I've probably got a good archive now, and the layer info just got lost in the repair process. I'm a bit concerned, though, because the 44gb first capture and 52gb second capture together only give me an 87gb archive. Am I missing something here?
2008-03-05 22:00:00.362 -0800 Minutia Waiting for permission to open archive [2.733106.569.8]
2008-03-05 22:00:06.079 -0800 Minutia Acquired permission to open archive [2.733106.569.9]
2008-03-05 22:00:06.081 -0800 Capture MBPHD [2.733106.569.10.1]
2008-03-05 22:00:06.093 -0800 Details MBPHD [2.733106.569.10.1.1]
2008-03-06 01:08:22.284 -0800 #debug# Reopened log file [2.733106.569.12]
2008-03-06 01:08:22.152 -0800 Failure Could not capture Localizable.strings [2.733106.569.11]
2008-03-06 01:08:22.391 -0800 Details File: MBPHD:Libraryrinters:EPSON:InkjetPrinterrintingModuleXG900_Core.plugin:Contents:Resources:Japanese.lproj:Localizable.strings [2.733106.569.11.1]
2008-03-06 01:08:22.404 -0800 Caution Problems processing items [2.733106.569.13]
2008-03-06 01:08:22.405 -0800 Details archive I/O error [2.733106.569.13.1.1]
2008-03-06 01:08:22.405 -0800 Details Data exception [2.733106.569.13.1.1.1]
2008-03-06 01:08:22.405 -0800 Subrosa .Explain: datawrio [2.733106.569.13.1.1.2]
2008-03-06 01:08:22.406 -0800 Details Cause: <IO> cannot read envelope data { PkgNumber=2128924, Class=FileSource@0x133a70(/Volumes/spare/bu-archive.quanta/repository.data), API=FSReadFork, Pos=45118276456, OSErr=-5000, Length=8828, File=/Volumes/spare/bu-archive.quanta/repository.data } [2.733106.569.13.1.1.3]
2008-03-06 01:08:22.406 -0800 Details Path: MBPHD:Libraryrinters:EPSON:InkjetPrinterrintingModuleXG900_Core.plugin:Contents:Resources:Japanese.lproj [2.733106.569.13.1.2]
2008-03-06 01:08:22.406 -0800 Failure Could not process folder Japanese.lproj [2.733106.569.13.1]
2008-03-06 08:10:34.907 -0800 #debug# Reopened log file [1.733106.245.25]
2008-03-06 08:10:34.906 -0800 Minutia Saved Capture MBPHD to bu-archive.quanta action [1.733106.245.24]
2008-03-06 08:10:34.929 -0800 Details file: /Users/ralph/Library/Preferences/QRecall/Actions/bu-archive.quanta-capture (2).qraction [1.733106.245.24.1]
Ralph Strauch wrote:2008-03-06 01:08:22.152 -0800 Failure Could not capture Localizable.strings
2008-03-06 01:08:22.405 -0800 Details archive I/O error
2008-03-06 01:08:22.406 -0800 Details Cause: <IO> cannot read envelope data { PkgNumber=2128924, Class=FileSource@0x133a70(/Volumes/spare/bu-archive.quanta/repository.data), API=FSReadFork, Pos=45118276456, OSErr=-5000, Length=8828, File=/Volumes/spare/bu-archive.quanta/repository.data }
What's odd is the error code. Error code -5000 is normally an access error to a file on a network volume, not a USB device. But then again, you said that you're using some special USB drivers? That might be a factor.
The log file didn't get attached. You can just mail it to james@qrecall.com and I'll take a look at it.Ralph Strauch wrote:I'm attaching a file containing the log starting at the point that I mounted the backup drive.
That, by itself, will not cause the repair to fail. It's just an informational message telling you what QRecall found wrong with the archive. The repair is specifically designed to discard errors and corrupted data and reconstruct the archive from all of the data that still OK. What you want to look for is either "Repair complete" or "Repair failed".I restarted the backup at 2008-03-13 01:43:51.499 and it failed due to an invalid header length. I started a repair at 2008-03-13 01:48:19.045 and went to bed. When I got up the next morning I found that the repair had failed almost immediately at 2008-03-13 01:48:20.562 due to "Found 24 bytes of invalid data at file position 2424."
If the volume unmounted, then that's a good reason why the Repair would fail.It also looks "from the log as if the backup disk was dismounted shortly thereafter. It was not mounted when I checked it in the morning.
My money is still on a problem with that drive or your FireWire interface. QRecall will never cause a drive to dismount. However, a drive that spontaneously dismounts will certain wreak havoc with any application that is writing to it, including QRecall. The error you encountered before was due to a write failure on that drive. Since the same thing happened again, I assume that QRecall encountered another write failure while trying to write to that drive.To help you interpret the log, MBPHD is the source drive on my MacBook Pro being backed up. "spare" is the backup volume, and the backup disk also contains volumes "leopard" and "Mac OS X Install DVD." The unmounted backup disk is the same condition I described on March 8. I assumed then that it was a problem with my drive, but now seeing it occur again immediately following a Qrecall failure I wonder if that is the case. Can you tell from the logs? Are some of these problems with my system, or is it all due to QRecall?
It does. If a call to the operating system fails, QRecall will exit gracefully. However, if a call to the operating system hangs there's nothing QRecall can do about it; it isn't in control of the process anymore. I might be able to tell more when I see the log file.In any case, I think QRecall needs a softer failure mode, allow the program to exit properly without requiring a force quit and sometimes even a reboot.
Yes. First, QRecall is always active. The scheduler and monitor processes run continuously. I've left a lot of debugging messages in the log to help diagnose any potential problems. Diagnostic messages that provide little use over time eventually get turned off.The log file also includes a lot of entries for time periods when QRecall isn't active. Is this normal?
Filename | strauch log 0321.txt |
Description | log file from remoter backup failure |
Filesize | 15 Kbytes |
Downloaded | 21100 time(s) |
Download |
Filename | strauch log 0321.txt |
Description | log file for failed remote backup |
Filesize | 15 Kbytes |
Downloaded | 22328 time(s) |
Download |
No, this is a bug in the JForum software that runs this forum. It can usually be avoided unchecking the "Disable HTML in the message" option. I don't know why.Ralph Strauch wrote:Here's log for my previous posting. I attached it to that posting and it showed up as attached, but the post itself showed up with <br>'s in place of the returns, I guess because I wrote it in a text processor and pasted it in.
James Bucanek wrote:
I'm profoundly sorry to be the bearer of bad news (again), but using QRecall with Apple's iDisk service does not work well.
There was a long thread on this some time back (Online Storage). To avoid the pain of reading the whole thing, I'll summarize:
According to this technical support article all you should have to do is wait 24 hours:Ralph Strauch wrote:I have one remaining problem I wonder if you can offer any advice about. I've deleted the empty qrecall archive from the idisk, but it still shows only 2.4gb of free space rather than the 5.8gb I had before the backup. Apparently it allocated 3.4gb of space for the qrecall archive even though it didn't use it, still keeps that space as used, even though it doesn't show up as allocated to any particular folder. Do you know anything I can do to get that space back?