jhg

It appears from my experimentation that Retrospect does not follow junction points and backup the files from the junction's target. Is there a way to control this behavior (i.e. a "follow links" option)?

You were, and somehow I missed your original post. Thanks! This looks like a trivial bug that should be fixed -- at least I hope so.

After a couple of posts in the bug report, here is a workaround, and my assessment (as a 40-year career developer) of where the bug is. Retrospect support suggested that I could try to open the moved catalog file by double clicking on it (the catalog file) to launch Retrospect. Here is my latest response on the bug ticket:

Understood; the support case is number 73057. I've been a user of Retrospect since one of the earliest versions on a Mac SE30 (backing up to 1.44MB floppies) and generally been satisfied, but I agree that bugs linger for ages before being addressed. But glacial bug resolution pace seems to be the norm -- see Apple, Microsoft, Quicken, etc.

I have opened a support case. https://www.retrospect.com/en/support/case?case_id=5000P00000q2rrJQAQ

OK, there is definitely something very broken in how Retrospect locates the catalog. I rearranged the drive letters to make the image backup disk E: again, and it has no trouble, just opens the backup set and does not prompt for the catalog location. This indicates to me that Retrospect is storing the catalog drive and path in its metadata. If it's not possible to read a catalog from a different location than what is saved in Retrospect's metadata, then it shouldn't be presented as an option. Clearly that is not what is intended, so Retrospect should be able to update its metadata to read the catalog from a different location.

None of this makes any intuitive sense. I created a backup set on a hard disk, and placed the catalog (from the start) on the same disk. At the time, the backup set was in E:\Retrospect, and the catalog ("DRImage.rbc") was in e:\catalog. Now I'm trying to restore a file from that image. The disk is now H: after a reinstall of Windows 10. When trying to open the backup set it asks "Where is the Catalog File for DRImage". When I navigate to H:\catalog, no matter what I do it says it cannot find the file. This seems awfully broken to me. If I point it to the catalog, it should find the catalog. The catalog was updated just yesterday, the only thing that has changed is that the drive letter has changed.

The Properties dialog for a backup set does not allow changes to the catalog file location:

OK, so I moved the catalog file to the desired location, then ran the backup script. It asked me "Where is the Catalog File for " the backup set. When I navigated to the new location and selected the catalog file it says "File Not Found" If I select the parent directory of the catalog file instead it says "The name is not valid" I see other messages in the forum about this problem in the context of attempting a disaster recovery restore... this does not inspire confidence that DR will actually work. Why does it not accept the new location of the catalog file?

Retrospect 16.6.0.133 Given an existing backup set, is it possible to change the location where the catalog file is written? I have a Disaster Recovery backup for my C:\ drive that writes its catalog into a directory on D:\ and I'd like to change it to put the catalog on the same disk as the backup set itself. Can I alter the backup set? I don't see a way to do this from the "Properties" dialog.

@DavidHertzberg no, I never alter the settings, this is from a standard archive script I run regularly. @x509 no, I don't run the archive while Lightroom is running... although it's conceivable I accidentally left Lightroom in the background during an archive run. Since the file on disk compares correctly with the restored copy, and chkdsk /r on the drive turns up no errors, I'm not going to worry about this one.

The disk is USB3 and normally has worked flawlessly. I ran the verify again on one of the archives and it flagged the same file again. Is there a way to make Retrospect archive that one file again?

I have a large (2.5TB) library of images on disk, for which I keep two separate Retrospect disk archives. Occasionally (once or twice per year) run a Retrospect media verify on both archive drives. This time around I got a single verify error on each drive, flagging a different file on each drive. Here's one of them Here's the same file in Windows Explorer And in the Backup Set The only difference is that Retrospect seems to think that the file in the backup set is newer than the one on disk. I restored that single file to a temporary location and compared it to the original (still on disk at its original location) with WinMerge and the Windows "comp" command. Both WinMerge and "comp" report that the files are identical. Then I ran "chkdsk /r" on both drives, neither of which flagged any bad sectors or other filesystem errors. So I have 2 questions: What exactly does the error message mean? When was the "Generated MD5 digest" calculated (at backup time or during the verify)? Where is the "stored MD5 digest" actually stored? Since the original and restored copy of the file compare equal, I assume this is a problem in the backup set and/or catalog. How do I get Retrospect to "fix" this error and get itself back in sync?

I configured a daily email report to be sent at 7:00 AM, as shown in the attached screenshot. However, it appears that the email is sent only if the full Retrospect application is open at the requested time. I would have expected that the email would be generated by a small background process, such as retrorun.exe instead of the full app. If this it is intended that the email status requires the full app to be running, then I would like to submit a feature request that the task of sending the status email be moved to retrorun so that the main app does not have to be running.