Jump to content

Truncated path in log


danmargetts

Recommended Posts

All

 

The path to a file that is generating a "volume structure corrupt" error during backups, is being truncated in the Retrospect logs. An extract of the relevant part of the log is below with the path in question in bold:

 

- 28/08/2007 23:00:36: Copying Documents and Settings on DanLapTop Internal HDD (C:)

While scanning volume DanLapTop Internal HDD,

Folder C:\Documents and Settings\Danim...,

Scanning incomplete, error -1123 (volume structure corrupt)

 

 

Whilst it is great to know that these errors are being picked up and flagged, this particular log is a tease because it is not telling me where to find the problem file! It is like giving a kid a candy without taking off the wrapper.

 

Can anyone advise me if it is possible to get Retrospect to record the full path? Or if I can find the full path somewhere else?

 

I have tried to get around this and find the error myself by copying and pasting the entire folder corresponding to that part of the path that I can see, but the directory tree is huge and of course the paste operation keeps generatinig access permission denials that are nothing to do with the real error. I have also searched these forums and the web for a clue but cannot find anything.

 

I am using Retrospect Pro 7.5.387 on XP SP2

 

Thanks!

Link to comment
Share on other sites

Thanks for the quick reply.

 

Yes. The file structure is NT and so I understand only the Windows CHKDSK utility can make the repairs at reboot (before Windows locks out the file structure). But the problem still remains.

 

What I want to do is to get the logging utility to write the path in full so I can find the file and delete it to see if that fixes the problem.

 

How can I get Retrospect to log the path in full? Is it normal behaviour to truncate the path? Is there a setting somewhere to generate comprehensive logs?

Link to comment
Share on other sites

Amy

 

Many thanks. Your suggestion was inspired as, in backing up the directory tree as a subvolume, Retrospect was then able to identify a bunch of files that it could not back up, whose paths it was able to log in full.

 

What is interesting about this is that the files in question related to an application that I had previously uninstalled, and that, last night, I was able to copy, paste and delete the files. My interpretation of the Retrospect error message was that there was corruption on the disk somewhere. But if that had been the case, my guess is (and it is a guess as I am by no means an expert!) then the copy / paste / delete operations would probably have failed. Therefore, I can only conclude that the uninstallation process somehow deleted some references to the files in a Windows index, but did not finish the job and left them visible on the disk. This confused Retrospect, which probably had a hard time figuring out if the files were actually there or not!

 

Anyway, having deleted the unwanted files, I then ran the backup again (normal) and was delighted to see that no further errors were reported. The main backup runs again tonight, and I have my fingers crossed! I will let you know the result tomorrow.

 

Thank you again, Amy.

 

Dan

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...