amkassir Posted November 4, 2010 Report Share Posted November 4, 2010 (edited) When doing a backup of my boot partition, the backup completes successfully. The verification is reported as successful, but there are 439 files "remaining." Does this mean my verification didn't succeed for 439 of the files? Or did the verification succeed but is incorrectly reporting 439 files remaining? I've read this thread in the Retrospect 8 bug reports forum on the same issue, but it's still not clear to me whether the files were verified or not, and why many files are still "remaining." I'm using media (not thorough) verification. Here's the log: Normal backup using Backup iMac HD at 10/26/10 To Media Set Media Set A... - 10/26/10 9:50:27 PM: Copying iMac HD 10/26/10 9:59:42 PM: Snapshot stored, 177.1 MB 10/26/10 9:59:54 PM: Execution completed successfully Completed: 1649 files, 5.8 GB Performance: 1,628.7 MB/minute Duration: 00:09:26 (00:05:48 idle/loading/preparing) - 10/26/10 9:59:58 PM: Verifying Media Set A 10/26/10 10:02:23 PM: Execution completed successfully Remaining: 439 files, 3.9 MB Completed: 1210 files, 5.8 GB Performance: 2,590.9 MB/minute Duration: 00:02:25 (00:00:07 idle/loading/preparing) I hope I get some resolution to this question soon, because I'm halfway through the 30-day trial period for Retrospect 8.2. I'll upgrade from version 6.1 if I'm comfortable with 8.2, but until I understand what's going on here, I'm not comfortable with the integrity of the verification process. BTW, I submitted this same question to tech support 9 days ago--7 business days--but haven't received a reply so I thought to post it here. Thanks for any insight you can offer. Edited November 4, 2010 by Guest Quote Link to comment Share on other sites More sharing options...
amkassir Posted November 10, 2010 Author Report Share Posted November 10, 2010 I received a welcome response from Roxio Support on this issue: Although your backup completed successfully, the final report shows several files remaining because you are using Media verification. If you use Thorough Verification there shouldn't be any files left over after the backup completes and you can ignore the "remaining file" reported by Media Verification. I hope to have a chance to test this over the next few days and will report back here. Can anyone else confirm the quoted material above? Quote Link to comment Share on other sites More sharing options...
sleitner Posted November 10, 2010 Report Share Posted November 10, 2010 Hello amkassir, the real reason for the remaining files during media verification is that files with "/" in the filename are not verified or correctly counted as verified. May be more files are affected, but this like searching a needle in the haystack, if you don't have a clue what to search for. It was pure luck to find the "/" file clue. Roxio (formerly Iomega) was absolutely no support in this case. Normally the files are save, but without an automatic verification, you can't trust what's on your backup media or not. Roxio support (formerly Iomega) knows about this problem since January 2010, but for them it is not important enough to fix it. May be next year in a new version... Roxio only provides workarounds like switching to Thorough Verification, but this is not an option if you backup files which changes often during the backup/verification task. The next argument of Roxio is that "/" filenames are not allowed on all operation systems. But on OSX they are very common, even system files have "/" filenames. And it is possible to rename files with "/" using Finder and other applications without error message. Retrospect should backup, verify and restore all valid files on any supported system. With version 6 it has been no problem as well. Quote Link to comment Share on other sites More sharing options...
Maser Posted November 10, 2010 Report Share Posted November 10, 2010 I would probably argue that "/" in OSX file names will probably become less common than you think. Office 2011 (as a recent example) won't let you open files with a "/" in the name -- and this was not changed in yesterdays 14.0.1 patch, either. Whether or not this is a good or bad thing, is debatable. Quote Link to comment Share on other sites More sharing options...
CallMeDave Posted November 10, 2010 Report Share Posted November 10, 2010 The next argument of Roxio is that "/" filenames are not allowed on all operation systems. But on OSX they are very common, even system files have "/" filenames. Uh, no. "/" is not a permissible character for OS X's underlying BSD subsystem. And it is possible to rename files with "/" using Finder and other applications without error message. Yes, but the Finder is lying to you. If you inspect such a file using tools other then Finder, you'll find the actual character in the name is ":" Retrospect should backup, verify and restore all valid files on any supported system. Agreed. Which leads to the logical conclusion that files with "/" in their name should fail. With version 6 it has been no problem as well. Retrospect "Classic" was blind to OS X filesytem realities; it was simply a Carbonized version of Retrospect 4. The fact that it didn't choke is not related. Quote Link to comment Share on other sites More sharing options...
rhwalker Posted November 10, 2010 Report Share Posted November 10, 2010 Uh, no. "/" is not a permissible character for OS X's underlying BSD subsystem. Yes, but the Finder is lying to you. If you inspect such a file using tools other then Finder, you'll find the actual character in the name is ":" Retrospect "Classic" was blind to OS X filesytem realities; it was simply a Carbonized version of Retrospect 4. The fact that it didn't choke is not related. Consider the case of a terabyte of historical files brought forward from MacOS 7, 8, 9 and ASIP 4.x into MacOS 10.x, with historical backups from Retrospect 2.0, 4.x, 6.x, etc. I've got that existence proof with such oddly-named files. No, a script can't do a search and replace for legal reasons - the files have to retain their names. Agreed, it's a dilemma. Russ Quote Link to comment Share on other sites More sharing options...
sleitner Posted November 10, 2010 Report Share Posted November 10, 2010 The point is, I can't change the names. Many files are linked with the file name as reference. Or they are received from clients and we are not allowed to change the file names. So then the ":" in the BSD filenames would be the real reason, depending which library retrospect uses to access directories and files. I think until OS9 ":" has been the folder character and "/" has been a valid filename character. Failing handling this files would be consequent, but this would upset users, because the software doesn't do what the user think it does: - securely backup ALL files on the system irrespective of the "beauty" of their file names - files can be automatically verified - files can be later restored to the same status as before. Otherwise this backup application is no secure way to backup your files. Quote Link to comment Share on other sites More sharing options...
CallMeDave Posted November 10, 2010 Report Share Posted November 10, 2010 So then the ":" in the BSD filenames would be the real reason. I dunno; that's not what I said. I replied to: "... it is possible to rename files with "/" using Finder..." in the present tense. Today's Finder will allow the user to use "/" and display it as such, while the file's actual name uses ":" For legacy files (such as Russ notes above) I don't know what a shell sees. Quote Link to comment Share on other sites More sharing options...
rhwalker Posted November 10, 2010 Report Share Posted November 10, 2010 The point is, I can't change the names. Many files are linked with the file name as reference. Or they are received from clients and we are not allowed to change the file names. Agreed. I'm in the same boat. So then the ":" in the BSD filenames would be the real reason, depending which library retrospect uses to access directories and files.I think until OS9 ":" has been the folder character and "/" has been a valid filename character. Failing handling this files would be consequent, but this would upset users, because the software doesn't do what the user think it does: - securely backup ALL files on the system irrespective of the "beauty" of their file names - files can be automatically verified - files can be later restored to the same status as before. Otherwise this backup application is no secure way to backup your files. Agreed. It's a bug. One of many. Perhaps someday some of the outstanding bugs will be fixed. I suggest that you file an incident report to make sure that this gets on the list and prioritized. These forums are user-to-user support. The official bug reporting page is here: File a support request Russ Quote Link to comment Share on other sites More sharing options...
amkassir Posted November 11, 2010 Author Report Share Posted November 11, 2010 Just out of curiosity I did a simple test. I made a backup of a folder containing 3 files. One file had a "/" in the name. The first time I did a media verification. The verification was successful with 1 file remaining. Then I did the same backup (recycling the media) with thorough verification. The verification was successful with no files remaining. Finally, I changed the name of the file, replacing the "/" with a dash "-". I did the same backup (recycling) with media verification. The verification completed successfully with 0 files remaining. Bottom line is I was able to reproduce the reported behavior of the media verification process when files containing the character "/" are backed up. What remains unknown is this: (1) Are the affected files (ones with the name containing a "/") properly verified or not, when using media verification? (2) Do other special characters in file names cause similar behavior? In my original post, I reported 439 files were remaining. I seriously doubt I have 439 files containing a "/" in their names. I typically make a point of NOT naming files with a "/" in the name. This leads me to suspect that other files are involved too. Unless Retrospect support can answer these concerns definitively, how can one be sure all these files are backed up properly and can be counted on to restore correctly? Quote Link to comment Share on other sites More sharing options...
amkassir Posted November 11, 2010 Author Report Share Posted November 11, 2010 I have filed this problem as a support request (and waiting for support to answer my 2 questions above). I also posted a summary of this issue in this thread in the Retrospect bug reports forum. Quote Link to comment Share on other sites More sharing options...
amkassir Posted November 12, 2010 Author Report Share Posted November 12, 2010 Bad news. When files are "remaining" after a "successful" media verification, those files were NOT verified. I have received a response from our escalations team. That the files are not being properly verified when they contain special characters. / is the only character we have identified so far that causes the issue. We have a bug open for this, and Engineering will be reviewing it to identify any other characters that cause the problem. This means that only thorough verification works for these files. Quote Link to comment Share on other sites More sharing options...
Maser Posted November 12, 2010 Report Share Posted November 12, 2010 It doesn't necessarily mean that the files weren't properly backed up, though. Quote Link to comment Share on other sites More sharing options...
amkassir Posted November 12, 2010 Author Report Share Posted November 12, 2010 Yes, only that they are not verified to be properly backed up. Quote Link to comment Share on other sites More sharing options...
baweeks Posted November 30, 2010 Report Share Posted November 30, 2010 A few months ago Robin replied to another thread, just about this issue, that this is a "cosmetic bug" and it shouldn't be worried about, and he said that one could be confident that verification was OK. I would be more confident if Retrospect put up a KB saying that such files were DEFINITELY verfied, and that the bug is only in the *reporting8 of same. I agree that Retrospect reporting a large x number of files as not being verified using media verification is a confidence-reducing issue. If it truly is not verifying files starting with /, then they should post a KB about this, offer a workaround other than the time-consuming full verification, or find a way to fix the issue of backing up and/or reporting of / files. -baweeks -baweeks Quote Link to comment Share on other sites More sharing options...
amkassir Posted December 1, 2010 Author Report Share Posted December 1, 2010 I agree, a KB article would be nice. I would hope the response from Roxio Support (quoted above) would be accurate, although it's not the answer I was hoping for. Let's hope a fix comes soon. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.