<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
	<channel>
		<title><![CDATA[Latest posts for the topic "unrepairable archive"]]></title>
		<link>https://forums.qrecall.com/posts/list/6.page</link>
		<description><![CDATA[Latest messages posted in the topic "unrepairable archive"]]></description>
		<generator>JForum - http://www.jforum.net</generator>
			<item>
				<title>unrepairable archive</title>
				<description><![CDATA[ I have an archive that I can't open, that keeps telling me the index needs repair. When I try to repair the archive, the repair appears to run normally, then fails to complete and close the file when it's done. This happens with the drive mounted on two different computers. Both Disk Utility and TechTool Pro give the drive a clean bill of health. Can you tell from the Report whether the problem is with the archive or with the drive, and if the former, how I can repair it?]]></description>
				<guid isPermaLink="true">https://forums.qrecall.com/posts/preList/622/2952.page</guid>
				<link>https://forums.qrecall.com/posts/preList/622/2952.page</link>
				<pubDate><![CDATA[Thu, 26 Jan 2017 12:45:46]]> GMT</pubDate>
				<author><![CDATA[ Ralph Strauch]]></author>
			</item>
			<item>
				<title>Re:unrepairable archive</title>
				<description><![CDATA[ Ralph, <br> <br>I think it's the drive, but I need some more information to connect the dots. <br> <br>The log included in your reports contains thousands of errors like this one: <br> <br>[code]2017-01-26 04:34:30.152 -0800 IO exception <br>2017-01-26 04:34:30.152 -0800 POSIXErr: 2 <br>2017-01-26 04:34:30.152 -0800 Path: /Volumes/BUD2/2nd backup.quanta/repository.data <br>2017-01-26 04:34:30.152 -0800 ErrDescription: No such file or directory[/code] <br>This would indicate that the volume spontaneously unmounted while the repair was in progress. The repair is designed to tolerate I/O errors, and will keep plowing away, trying to read whatever data it can, so this just goes on, and on, and on. <br> <br>The build in Send Report function only includes the latest log records, so to confirm my suspicions I'd need to more of the log. If you can, compress the files in ~/Library/Logs/QRecall and send them to me. They're likely to be very large, so I'll email you a dropbox upload request seperately. <br>]]></description>
				<guid isPermaLink="true">https://forums.qrecall.com/posts/preList/622/2953.page</guid>
				<link>https://forums.qrecall.com/posts/preList/622/2953.page</link>
				<pubDate><![CDATA[Thu, 26 Jan 2017 16:52:33]]> GMT</pubDate>
				<author><![CDATA[ James Bucanek]]></author>
			</item>
			<item>
				<title>Re:unrepairable archive</title>
				<description><![CDATA[ Following up, <br> <br>All of your repairs that I've looked at fail because the volume containing the archive spontaneously unmounts during the repair process. Here's an example of a repair that started at 09:49: <br> <br>[code]2017-01-21 09:49:40.052 -0800 Repair 5th backup.quanta <br>2017-01-21 09:49:40.052 -0800 archive: /Volumes/volume2/5th backup.quanta[/code] <br>Four hours later the volumes mysteriously, and spontaneously, unmounted. (Note that this doesn't appear to be associated with a sleep event.) <br> <br>[code]2017-01-21 13:34:42.401 -0800 unmounted volume /Volumes/volume2 <br>2017-01-21 13:34:42.402 -0800 unmounted volume /Volumes/volume1[/code] <br>Not surprisingly, the repair starts encountering problems?about a million of them: <br> <br>[code]2017-01-21 13:34:41.999 -0800 problem getting volume statfs <br>2017-01-21 13:34:41.999 -0800 IO exception <br>2017-01-21 13:34:41.999 -0800 POSIXErr: 2 <br>2017-01-21 13:34:41.999 -0800 Path: /Volumes/volume2/5th backup.quanta/repository.data <br>2017-01-21 13:34:41.999 -0800 ErrDescription: No such file or directory[/code] <br>This is most often caused by some intermittent hardware problem (failing drive controller, brief power interruption, flakey USB connection, and so on). <br> <br>QRecall can actually be helpful in diagnosing this. Because the QRecall scheduler watches for volume mount and unmount events, it logs those when they occur. Filter out everything except the scheduler messages in the log, and then look for unmount events that shouldn't be happening. If your a command-line geek, this will also do the trick: <br> <br>[code]fgrep ' [3.' ~/Library/Logs/QRecall/QRecall.log* | fgrep mount[/code]]]></description>
				<guid isPermaLink="true">https://forums.qrecall.com/posts/preList/622/2954.page</guid>
				<link>https://forums.qrecall.com/posts/preList/622/2954.page</link>
				<pubDate><![CDATA[Sat, 28 Jan 2017 11:41:27]]> GMT</pubDate>
				<author><![CDATA[ James Bucanek]]></author>
			</item>
	</channel>
</rss>