Long Closing Times fixed?

[benlevi]

I am amazed that in all the forums I've spent the past hour looking through, I still cannot find an answer as to why Retrospect 5.0.238 running Mac 10.3.2 takes many hours to Duplicate an internal hard disk onto an external firewire drive, with 90% of the time spent Closing each file separately. I know it has something to do with the Permissions, but so far it's very cloudy as to what, if anything can be done about that. Retrospect 6 info doesn't say anything about it, so I hope there's a clear and easy answer to the following:

 

1) For faster Duplicates, should the external firewire backup drive have "Ignore Permissions" box checked or unchecked?

 

2) When Duplicating and Replacing Corresponding Files, why does Retrospect 5.0.238 seem to want to check all 150,000+ files on the backup drive when it is Closing (I assume that's why it's taking so long...12 hours sometimes to close), when there might only be 1,000 files that actually need backing up.

 

3) Does Retrospect 6 Desktop change this behavior in any way? I need my system to be able to back up my data like it used to before I upgraded to Panther...it would only take about 10 minutes and that was it.

 

Thanks for your assistance.

[Mayoff]

The "closing Time" when Retrospect is saving the permissions has not been increased in 6.0.

 

If you "ignore permissions" on a disk, you may see some better speeds.

[pringsmuth]

I have noticed that when there are long closing times when duplicating to another hard drive the following:

 

Activity Monitor will show a process called (null) whose owner is the username. The parent process of (null) is WindowServer. (null) will be using a large percentage of processor time. WindowServer may be using a large percentage of processor time also. If you select the (null) process and force quit it, Retrospect will immediately speed up its closing process.

 

I have seen the closing process crawl to closing less than one file per second on my dual 2Gig G5.

 

I haven't yet figured out what is starting the (null) process.

 

Perhaps this will give someone a clue to build upon to solve this problem. I'm currently using Retrospect 6.0 under Mac OS X 10.3.2.

[pringsmuth]

I have now determined that starting Classic starts the (null) process. Quitting Classic also quits the (null) process.

 

I would suggest trying to run Retrospect without Classic running and see if that decreases closing times.