Hello,

after upgrading to beta 58 (though I fear the beta may nothing have to do with this), yesterday my scheduled capture reported my archive needed a repair. However, trying to repair it failed with a "disk or network error". Repairing the volume the archive is on showed no problems, the structures seemed to be fine. I then examined the archive package and found all files seemed to be fine with reasonable sizes, except for the file "package.index", which had a file size of 0 bytes.

I assume that this file is vital (and leads to the above error because it is empty), and that without the info in that file, the archive contents cannot be recovered by any means. Am I correct?

Thanks, Christian

Christian,

The fact that your package.index file is 0 length is just one indicator that you were unable to repair the archive. And although the other .index files appear to be reasonable lengths, none of them are usable either.

All of the information about your archive is stored in the repository.data file. The various .index files all contain information found in the repository.data file, organized for efficient retrieval. When you repair or reindex an archive, mostly what QRecall is doing is rebuilding the information in the .index files from the data records in the repository.data file.

Christian Roth wrote:However, trying to repair it failed with a "disk or network error".

This is the real problem. It's almost a tautology to say, but if QRecall can't read the contents of the repository.data file, you can't use the archive, which includes reconstructing the index files.

QRecall has a repair mode for recovering an archive on a device with unrecoverable media failures. Prepare a second drive with enough free space to copy the archive, then select the repair command and skip over the volume repair. Uncheck the "Use auto-repair" option and check "Copy recovered contents to new archive". Under these circumstances, I also recommend the "Recover lost files" option. When you start the repair, QRecall will prompt you for a destination. It will then proceed to copy everything it can from the existing archive to the new archive; anything that can't be read will be omitted.

Note that if the source drive is encountering I/O errors, this process can take an extremely long time to work. Most drives will take a lot longer to read a region of the drive that's failing than it would normally, sometimes a 100 times longer.

Also be aware that there are lots of causes for slow hard drive deaths, one of which is heat. If you have one of those "whisper quiet" external drives, it may be overheating. I was recently able to recover almost all of the data from an archive on an external drive, that wouldn't even mount for a friend of mine, by pulling the drive out of the enclosure and running it with an external fan blowing on it.

Christian,

I received your diagnostic report, and I'd like you to try something.

Attempt to repair your archive again, but this time make sure you unselect the "Use auto-repair information" option before starting.

Afterwards, please send another diagnostic report so I can compare the results.

Thanks.