Cannot Perform Immediate Backup - Log Reports Catalog Locked

[juliancarr]

I upgraded to v6 Desktop so that I could overcome the two problems I was having with version 5 when doing an immediate file backup to a firewire drive from Mac OS 10.3.2.

 

- I had to run the backup twice to overcome a locked catalog report in the first attempt.

- Once Retrospect had been run one or more times, the drive could not be unmounted.

 

These problems persist in v6 but are worse because under no circumstances can I do an immediate backup after the initial creation of the backup set. I have tried:

 

- Repairing permissions. Not applicable because the drive does not contain a system.

- Repairing the backup file. Does nothing.

- Reformating the drive. No change.

 

The firewire drive also contains a backup file from my OS9 computer created and maintained using version 5. This functions normally as Retrospect has always done for me, up to the introduction of Panther.

 

If anyone has any suggestions, I would be delighted to hear them.

[Mayoff]

Did you create new backup sets for Retrospect 6.0? 5.x backup sets are locked and read only in 6.0

[juliancarr]

Yes, several times. The result is always the same - subsequent backups can't be done.

[CallMeDave]

There have been occasional reports of this since Retrospect 5 first came on the scene. I don't think an answer has ever been given.

 

As I recall, one comon thread is that the catalog is always stored on an external FW drive. Often by LaCie.

 

Is this a split catalog?

Is the catalog file compressed?

 

You use Terminal to get some more info on this. Type:

 

ls -lo

and then drag and drop the catalog file onto the Terminal window, then press Return. What does it show?

 

 

Dave

[juliancarr]

Thank for your help Dave. To answer your questions:

 

Is the catalog split? No.

Is the catalog file compressed? I believe so.

What does the terminal window show?

 

[Julians-G4PB-Computer:~] julian% /Volumes/OzCAD\ Backup\ HD40B/Powerbook\ Backup\ HD40B.cat

tcsh: /Volumes/OzCAD Backup HD40B/Powerbook Backup HD40B.cat: Permission denied.

 

This was after I had just repaired the permissions on my computer. I am the only user on this machine and the FW drive is set to Read and Write for all it contains. The Permissions denied thing is probably why the drive can't be ejected once Retrospect has been launched and quit.

 

I do not see this when backing up using Retrospect v5.0 from OS9 to the same drive (different set obviously). It only started happening after I upgraded to Panther (10.3.2).

 

Does this offer any more clues?

 

[CallMeDave]

Quote:

---

[Julians-G4PB-Computer:~] julian% /Volumes/OzCAD\ Backup\ HD40B/Powerbook\ Backup\ HD40B.cat

tcsh: /Volumes/OzCAD Backup HD40B/Powerbook Backup HD40B.cat: Permission denied.

 

---

 

The shell can't run a file that it doesn't understand, which is what you've tried to do by simply calling the path and pressing return. Permission denied is normal for this command (try it on any file).

 

As I suggested in my previous message, you should type:

 

ls -lo "space" (where "space" is a single space character)

 

and _then_ drag and drop the file, and then press return.

 

I also note that the file you're using has a ".cat" file extension. Backup Sets created by Retrospect do not have any file extension; but when the program splits a File Backup Set it creates two files, and the second file _does_ have that extension. So I have to question your answer that this is not a split File Backup Set. Check Configure->Backup Sets->Configure->Summary; what does the Summary say?

 

DAve

[juliancarr]

Thanks for your help Dave.

 

>The shell can't run a file that it doesn't understand, which is what you've tried to do by simply calling >the path and pressing return. Permission denied is normal for this command (try it on any file).

 

No, I only get permission denied on the Backup file and catalog files.

 

>As I suggested in my previous message, you should type:

>

>ls -lo "space" (where "space" is a single space character)

>

>and _then_ drag and drop the file, and then press return.

 

This is exactly what I did. When you enter ls -lo, you get 8 or 10 lines that appear, right? Anyway, read on.

 

>I also note that the file you're using has a ".cat" file extension. Backup Sets created by Retrospect do >not have any file extension; but when the program splits a File Backup Set it creates two files, and the >second file _does_ have that extension. So I have to question your answer that this is not a split File >Backup Set. Check Configure->Backup Sets->Configure->Summary; what does the Summary say?

 

Now you're onto something. When I created the backup set, it was not split. The process of running a subsequent backup after the initial one reports one of two errors:

 

1. Can't save Snapshot in Powerbook Backup HD40A, error -25040 (catalog invalid/damaged).

 

In this case, I was just able to use Tools->Repair to rebuild the catalog, then Configure->Backup Sets->Configure->Options->Combine to recombine the catalog. Once done, I can successfully do one additional backup.

 

2. Can't add to backup set Powerbook Backup HD40B: The catalog is locked.

 

With this error is encountered, Retrospect splits the catalog file and adds the .cat file extension to the catalog (the original backup was not configured to have a split catalog). After using Configure->Backup Sets->Configure->Options->Combine to recombine the catalog, I can then do a backup. After doing the backup, there is still a separate catalog file, even though Configure->Backup Sets->Configure->Options reports it as combined.

 

If I unmount/remount the drive and try to do an immediate backup again, the same problem reoccurs and the same solution applies. With a subsequent backup, a new problem occurs. If I double click the backup set to launch Retrospect, I now get the following alert:

 

Sorry. No appropriate encryptor available.

 

If I try to combine the catalog again, I get an alert that the catalog file is not a catalog file or is heavily damaged. Furthermore, Retrospect has created hidden file on the FW drive with no name and a random icon, that only appears in Backup Sets window. It can be deleted with the Forget button.

 

Once again let me say that both these drives function normally in all other respects, including when connected to an OS9 machine running Retrospect 5.0.

 

I am getting ready to start looking for other solutions. Not having a reliable daily backup is not worth contemplating.

 

Thanks again for your help Dave.

 

[juliancarr]

After reformatting both my firewire drives [Mac OS Extended (Journaled)] and creating new backup sets on each with separate catalog files and no compression, I can update backup sets with the following work around:

 

1. Launch Retrospect 6 and perform an immediate backup. Nothing backed up - log reports locked catalog.

 

2. Log out and log back in using the same login name and password as before.

 

3. Launch Retrospect 6 and perform an immediate backup. Quit Retrospect.

 

At this point, the firwire drive cannot be ejected as it supposedly contains something in use. No apps are running. Repairing permissions from the OSX install disk makes no difference.

 

Perhaps this will help someone else. Perhaps it will be a clue to Dantz as to where things are going wrong. Until it is fixed I can no longer recommend Retrospect to any of our Mac OSX users - something I have done without reservation, to date.

 

[CallMeDave]

Quote:

---

After reformatting both my firewire drives [Mac OS Extended (Journaled)] and creating new backup sets on each with separate catalog files and no compression, I can update backup sets with the following work around:

 

1. Launch Retrospect 6 and perform an immediate backup. Nothing backed up - log reports locked catalog.

 

---

 

Obviously, this is not how Retrospect works for most users; there is something going on with your setup that needs to be discovered.

 

Some background on your previous messages.

 

Retrospect has a patent on the concept of keeping a catalog file that is separate and distinct from the data that's backed up. File Backup Sets originally kept the data and catalog information in a single file, with the data in the data fork and the catalog in the resource fork. Mac OS (both Classic and OS X) have a limit on the size of any file's resource fork and this limit was being reached in modern use. So Retrospect 5.0 brought in the ability to automagically split the catalog information out to its own file when necessary (it's the number of files that are at issue, not the total size of the backup).

 

So if Retrospect splits your File Backup, don't try and combine it later.

 

 

The information I suggested you get from Terminal is probably not related, although I can't let it go that you were not doing it right.

 

 

When applied to a single file, the "ls" command with the "-lo" flag will yield a single line of information.

Here is an example:

 

[mycomputer:~] curtis% ls -lo /Library/Fonts/Wingdings

-rwxrwxr-x 1 curtis admin - 0 19 Oct 2001 /Library/Fonts/Wingdings

 

In the example above, the first line is the command, followed by the path to the file. The second line is what the shell returns, which is specific information about the file. The "o" flag adds the column between "admin" and "0 19 Oct", represented in my example by a dash. If the results for your catalog files had information in that column, it would be helpful to know.

 

>If I double click the backup set to launch Retrospect, I now

>get the following alert:

>

> Sorry. No appropriate encryptor available.

 

Where is this error coming from? Is it a Retrospect error, or is it coming from the Finder?

 

This seems to me as if there's something wacked in your system. If the Finder is not associating the document's type (Retrospect documents include Mac OS Type/Creator information, and don't use file extensions to associate documents to applications) it may be trying to use the file for some purpose for which it of course wont' work.

 

What happens if you drag and drop the same file onto the Retrospect application icon?

 

>Until it is fixed I can no longer recommend Retrospect to any of

>our Mac OSX users - something I have done without reservation, to date.

 

If the issue is being caused by some problem with your system then your recommendations should be based on that.

 

Have you tried doing this with a different setup (I'm doing almost the exact same thing daily with no problems, File Backup Sets to an external 160 Gig FW drive from a PowerBook running OS X 10.3 and Retrospect 6.0)? A different computer to run the program with the same external drive, and/or a different external drive with the same or a different computer?

 

 

 

 

 

 

 

[juliancarr]

Thanks for your comments Dave.

 

>>Obviously, this is not how Retrospect works for most users;

>>there is something going on with your setup that needs to be discovered.

>>Some background on your previous messages.

>>Retrospect has a patent on the concept of keeping a catalog file that

>>is separate and distinct from the data that's backed up. File Backup

>>Sets originally kept the data and catalog information in a single file,

>>with the data in the data fork and the catalog in the resource fork.

>>Mac OS (both Classic and OS X) have a limit on the size of any file's

>>resource fork and this limit was being reached in modern use. So

>>Retrospect 5.0 brought in the ability to automagically split the

>>catalog information out to its own file when necessary (it's the number

>>of files that are at issue, not the total size of the backup).

>>So if Retrospect splits your File Backup, don't try and combine it later.

 

OK, I understand that now thanks.

 

>>The information I suggested you get from Terminal is probably not

>>related, although I can't let it go that you were not doing it right.

>>When applied to a single file, the "ls" command with the "-lo" flag

>>will yield a single line of information.

>>Here is an example:

>>

>>[mycomputer:~] curtis% ls -lo /Library/Fonts/Wingdings

>>-rwxrwxr-x 1 curtis admin - 0 19 Oct 2001 /Library/Fonts/Wingdings

>>

>>In the example above, the first line is the command, followed by the

>>path to the file. The second line is what the shell returns, which is

>>specific information about the file. The "o" flag adds the column

>>between "admin" and "0 19 Oct", represented in my example by a dash.

>>If the results for your catalog files had information in that column,

>>it would be helpful to know.

 

OK, I just tried this again with the catalog file (I only had a combined one before). Here is what it said, from start to finish:

 

Welcome to Darwin!

[Julians-G4PB-Computer:~] julian% ls -lo/Volumes/OzCAD\ Backup\ HD40B/Powerbook\ Backup\ HD40B.cat

ls: illegal option -- /

usage: ls [-ABCFGHLPRSTWZabcdfghiklnoqrstuvx1] [file ...]

[Julians-G4PB-Computer:~] julian%

 

 

>>If I double click the backup set to launch Retrospect, I now

>>get the following alert:

>>

>>Sorry. No appropriate encryptor available.

>>

>>Where is this error coming from? Is it a Retrospect error, or is it coming from the Finder?

 

Since I reformatted the drives, I am not seeing it any more. As I recall, it was coming from Retrospect.

 

>>This seems to me as if there's something wacked in your system. If the

>>Finder is not associating the document's type (Retrospect documents

>>include Mac OS Type/Creator information, and don't use file extensions

>>to associate documents to applications) it may be trying to use the file

>>for some purpose for which it of course wont' work.

>>

>>What happens if you drag and drop the same file onto the Retrospect application icon?

 

I certainly tried this option at the time and had also set Retrospect 6 to open the file in Get Info.

 

>>Until it is fixed I can no longer recommend Retrospect to any of

>>our Mac OSX users - something I have done without reservation, to date.

>>

>>If the issue is being caused by some problem with your system then your recommendations should be based on that.

 

Fair comment, though I thought I had done a fair job at checking everything, including using Disk Utility to repair the drive and permissions and reformatting the external drives. Everything else is functioning normally except for Retrospect.

 

>>Have you tried doing this with a different setup (I'm doing almost the

>>exact same thing daily with no problems, File Backup Sets to an external

>>160 Gig FW drive from a PowerBook running OS X 10.3 and Retrospect 6.0)?

>>A different computer to run the program with the same external drive, and/or a different external drive with the same or a different computer?

 

Yes, but not in OSX. From OS 9.2.2 using Retrospect 5.0 and the same external drives, it works flawlessly. BTW, the drives are are self powered 40 gig IBM Travelstar with the Oxford chipset that did not have the conflict with Panther experienced by some similar drives had. I will be getting another iMac in a few weeks to replace the OS9 machine, so will try that then.

 

Thanks again for your help Dave.

 

[CallMeDave]

Quote:

---

OK, I just tried this again with the catalog file (I only had a combined one before). Here is what it said, from start to finish:

 

Welcome to Darwin!

[Julians-G4PB-Computer:~] julian% ls -lo/Volumes/OzCAD\ Backup\ HD40B/Powerbook\ Backup\ HD40B.cat

 

---

 

You're missing the space between the command and the path to the file. That's why the shell is returning an error (which includes an example of how it should be entered, including the space. Unix is particular, but it's predictable.)

[juliancarr]

Sorry Dave - I'm slow if not persistent. Doing this stuff after midnight is not recommended.

 

I think this is correct now...

 

Welcome to Darwin!

[Julians-G4PB-Computer:~] julian% ls -lo /Volumes/OzCAD\ Backup\ HD40B/Powerbook\ Backup\ HD40B.cat

-rw-rw---- 1 julian unknown - 3647096 17 Feb 00:09 /Volumes/OzCAD Backup HD40B/Powerbook Backup HD40B.cat

 

Make any sense?

 

 

[CallMeDave]

Quote:

---

Sorry. No appropriate encryptor available.

 

---

 

I just saw this, and remembered that it had been mentioned on a post here.

 

Attempting to use Retrospect 5.1 to open a Catalog that was created in Retrospect 6.0 results in this error.

 

Makes sense. If you tried (for example) to open a Microsoft Word 6 document in Microsoft Word 5 (or 4, or 3) you wouldn't get a usable document. Old applications can't be expected to understand the file formats of newer versions (unless the developers had a time machine when they were coding...).

 

Is this what you're doing (not the time machine part, the Retro 6 catalog w/Retro 5)?

[ghoffman]

Quote:

---

Quote:

---

Sorry. No appropriate encryptor available.

 

---

 

Attempting to use Retrospect 5.1 to open a Catalog that was created in Retrospect 6.0 results in this error.

 

Is this what you're doing ...?

 

---

Dave: In the original report (message #36914) julian 5 reported "If I double click the backup set to launch Retrospect, I now get the following alert: Sorry. No appropriate encryptor available.".

 

Seems to me that if there is a copy of an earlier Retrospect anywhere on the system, then that copy of Retrospect might get the open request from the double click, with the reported error as the outcome.

 

jilian5: can you double click on the backup set now and get the error message? If not, then probably you corrected the problem when you reformatted the drives. Or removed the Retrospect CD from its drive. Or unplugged the other external hard drive. Or ...

 

Glenn

[juliancarr]

Thanks for your comments guys. Perhaps you are right. I do have version 5 still installed, but no longer get that problem since reformatting the drive.

 

I am still having the two problems this thread began with though - trying to backup reports catalog locked. Logging out then back in again fixes that problem, but is tedious workaround.

 

The other problem is most definitely a bug in Retrospect for mine. If I simply open and close the backup file, I can no longer eject the drive. It reports there is a file in use. This does not happen with any other application opening files from the drive, including InDesign 2, BBEdit 6.1, QuickTime Player 6.5, AppleWorks 6, VectorWorks 10.5, Toast Titanium 5.2, etc.

 

I also think the two problems are related and Retrospect is just not handling the simple process of opening and closing files correctly. Pretty basic stuff. BTW, once I get the backup happening, it does perform normally, as do restores.

[juliancarr]

Well, this problem persists on a brand new iMac running OS 10.3.3 and backing up with Retrospect 6.0.178. It is the only piece of software that creates these problems and given that the drive has been reformatted and I am seeing it on two different computers, can only lead me to say that Retrospect is screwing up the permissions (or something).

 

The same workaround fixes it on the iMac too - run the backup, get the error, log out, log in, run the backup again. Regardless, if a backup or restore is performed, the drive cannot be unmounted and reports a file in use. I have to shut down to remove the drive.

 

I open lots of other file to many other apps from this drive (and two other FW drives). Retrospect creates the same problems on all of them.

 

Different drives (all reformatted). Different computers. New backups. Same problems.

 

When I pay for an upgrade, I don't expect reduced functionality and inconvenience.

[menkor]

First time for posting here -- be gentle with me ...

 

I am using 6.0 to backup from my iMac to an external firewire HD. It's a WD 160GB internal drive, within an external drive enclosure purchased separately.

 

I also use one of the client licenses to back up my wife's Windows XP Pro to a separate backup set. For both backup sets, after rebuilding the (external, uncompressed) catalog, I can backup the drive. However, I MUST rebuild the catalog before I can do another backup. This holds for BOTH computers. The error message I get is that the backup set catalog is locked. I've tried running disk utility, and also tried running TechTool Pro 4.0 on the external drive. Makes no difference -- only thing that works is to rebuild the catalog. This is a real pain -- 3.5 hours to rebuild my iMac catalog, followed by 10 minutes to do the actual backup.

 

I had this problem with 5.0, and bought the upgrade to 6.0 hoping that would solve the problem. Very disappointing to see it still here. Any suggestions?

 

Thanks in advance.

 

Russ

[CallMeDave]

Quote:

---

I had this problem with 5.0, and bought the upgrade to 6.0 hoping that would solve the problem. Very disappointing to see it still here.

 

---

 

Were you using the same equipment before, when you had the problem using 5.x?

 

 

Dave

[menkor]

Dave,

 

I've been using the same equipment all along. Also, I forgot to mention. I too cannot unmount the drive -- says the drive is in use. The only files on the drive are the backup files and the catalog files, and Retrospect is not running. I've been turning the drive off to quit, and getting the usual warning that I need to unmount the drive before turning it off. Don't know if that is corrupting anything, but didn't know of a workaround (until I saw about logging off and re-logging on again. Might that be corrupting the backup sets?)

 

Thanks,

 

Russ

[juliancarr]

Russ,

 

Please try this.

 

1. Run the backup and after you get the message that the catalog is locked, quit Retrospect.

 

2. Log out then log in again with your drive still connected and powered up.

 

3. Run the backup again.

 

If this works for you, it is a lot quicker that rebuilding the catalog.

 

Let us know.

 

Julian

[juliancarr]

I have now worked out what the problem is.

 

If Retrospect is launched before the firewire drive is connected and the backup file is opened from the Finder, the backup works fine and the drive ejects normally.

 

If the drive is connected and Retrospect is launched by double clicking the backup file from the Finder, it reports the catalog locked problem and the drive cannot be ejected.

 

I confirmed this behaviour on two different computers.

 

Now Dantz, you know what to fix.

 

Julian

[CallMeDave]

Quote:

---

Now Dantz, you know what to fix.

 

---

 

You sure?

 

Youre steps to reproduce consist of two small bits of information; "external FW drive connected" and "Retrospecct double-clicked from the Finder."

 

Since these two steps do not creat any error on the single Powerbook that I use for backups, suggesting that such limited information will be enough for Dantz to know what to fix is hopeful at best.

 

The only way to provide the sort of information that can be useful to software developers is to start clean and include complete information on what you're using and what you're doing. The steps must have a reasonable likelihood of reproducing the error when someone else does it. That's not what you've done here.

 

Since you're reporting the same issue on two different computers, is there _anything_ that's common between the two? For example, is this the same external FW drive that you're moving between the two computers? If so, you're narrowing the problem down to being caused by the drive (since the software does not do this on other systems).

 

Note also that this is a user-to-user community support board. It is _not_ the official Dantz tech support path. The best way to interact with the company is to open a (for fee) support incident. If your issue turnes out to be a software defect you can request (and receive) a refund.

 

Dave

[CallMeDave]

When the OS X Finder alerts you to the fact that you cannot unmount a volume because there open files on it you should investsigate exactly what files are open and what applications have opened them.

 

There appear to be various ways to achieve this. Two that I've been able to come up with are the "lsof" and "fstat" tools.

 

From the command line you can type:

fstat | grep /Volumes/NameOfYourExternalDrive

 

This should return a list of open files on that drive.

 

Another route to take is to use lsof to see what programs are using files. This tool has way too many options for me to know the best way to use it, but there's a simple GUI for it called Sloth:

http://sveinbjorn.vefsyn.is/sloth

 

Unfortunatly, Sloth only lists processes belonging to the current user. And since Retrospect runs as Root, you need to launch Sloth as root. One way to do this is with Pseudo:

http://www.versiontracker.com/dyn/moreinfo/macosx/9608

 

Drag and drop Sloth onto Pseudo and then use the Filter to look for files open in /Volumes

 

Dave

[juliancarr]

Thanks for your helpful information Dave. If Dantz need more info to fix this problem, here it is.

 

1. I see this on three different self powered FW drives, two of which are different brands.

 

2. I see it on a 17" iMac and a 15" Powerbook G4 running either OS 10.3.3 or 10.3.4.

 

3. When any of the drives are mounted, Sloth does not report any process on the drive. Any other file or application launched from any of the drives does not exhibit the problem. Two of the drives have been completely reformatted in an attempt to solve this problem.

 

4. If when the drive is mounted, Retrospect is launched from the Applications folder, an immediate backup performed and Retrospect quit, there are still no processes running on the drive, though some RetroRun processes are still running on the main drive.

 

5. If the Backup file is launched by double clicking from the FW drive when Retrospect is not running, then quit with or without performing a backup, Sloth then reports that a RetroRun process still running on the drive and names the Backup's catalog file as the culprit. At this point Retrospect is definitely not running. If I kill that process in Sloth, I can then eject the drive.

 

I have always felt this is a Retrospect bug and I still don't see any evidence to the contrary.

 

At least now I have discovered a simple workaround which I am happy to use. Whether Dantz fixes the problem is up to them.

 

Thanks again for your help Dave.

 

Julian

[CallMeDave]

Your steps appear to recreate an issue that prevents an external FW drive to be ejected but do _not_ cause the "Catalog Locked" error that began this thread. If you are doing things differently then the steps I list below, you should post the differences.

 

 

 

This is likely a bug, but since the steps to prevent the volume from being unmounted seem to be quite narrow, and not the way most people would use the program, it doesn't seem like a bad one. Since double-clicking on a Retrospect catalog file provides no benefit over launching the program from its application icon, simply avoiding that action will avoid the problem.

 

 

 

Here is what I've been able to confirm:

 

 

 

Powerbook G3 Series

 

Mac OS X 10.3.4

 

Retrospect 6.0.193

 

External FW hard drive storing File Backup file

 

 

 

- Launch Retrospect by double clicking on the application icon in /Applications/Retrospect 6.0/

 

- Observe the RetroRun process will launch; note it's PID (ie: 1234)

 

- Type "ps -p 1234" and observe that the RetroRun process lives at /Library/StartupItems/RetroRun/RetroRun

 

(note: if this path is not present, Retrospect will create it when the program is launched (provided the "Automatically Launch Retrospect" preference is enabled in Preferences->Notification))

 

- Quit Retospect and the RetroRun process continues to live (as expected)

 

- Launch Retrospect the same way again and note that a new instance of RetroRun (with a new PID) is launched in place of the previously running one. Note this PID

 

- Type "fstat -p PID" (where "PID" is the number noted above)

 

- Entries for RetroRun will be shown. Note that the MOUNT colum shows only the root volme being used.

 

(Note: The man page for fstat describes the MOUNT colum as "...the pathname that the filesystem the file resides in is mounted on.")

 

- Quit Retrospect

 

 

 

- Double-click a catalog file stored on a non-boot volume (ex: /Volumes/Jeremy/)

 

- Note the new PID for RetroRun when it re-launches

 

- Type ""fstat -p PID" Note at least one entry is shown with /Volumes/Jeremy/

 

- Quit Retrospect; attempting to unmount Jeremy will fail with a "file in use" error

 

 

 

If the "Automatically Launch Retrospect" preference is off, the problem will not occur.

 

If Retrospect is launched from its application icon (or an alias, even if the alias is on a non-boot volume), the problem will not occur.