Locked items will hinder smart backup?
 

I have some files which are locked. They seem to pose a problem during smart backup. When the locked file is changed on the original drive, SuperDuper! tries to delete the older file on the backup volume and then tries to copy the new file to it. Both actions are not possible. See excerpt of log below. The locked files I'm referring to are inside a program called iNotePad - they are actually normal files!

Is this a general limitation of SuperDuper! or am I missing certain preference settings? All works fine when I erase the backup volume first.

Sincerely, Martin.

This may be a bug in SD!, Martin. Does this only happen when you lock the parent folder of a file (as opposed to the file itself)?

iNotePad
 

Dave, in my case I have only locked a file, not a folder.

Maybe it's the best if you perform also a test yourself with iNotePad. There's a demoversion available here: http://www.vojousoftware.com/inotepad.html

The file (note) which I'm locking is invisible to the normal user. All notes are stored inside a package. The log in my initial post shows the file path and the style of file names that are affected and used by iNotePad.

You basically lock a file (note) by clicking a lock icon in iNotePad's tool bar.

With PathFinder set to "Show Package Contents" I was able to dig into iNotePad's hidden structure. Indeed, it's just a simple .rtfd file that is locked! Owner is set to me (502), Group to admin (80), chmod is set to 755. Size is 794 bytes. It contained 3 items (the graphics). Type/Creator is not specified.

I have 9.9 GB free on my original disk. The target disk is the same.

But again, it's not a disc size related error, because (I had this in the past already) when unlocking the notes -- all works fine :)

Sincerely, Martin.

Right -- but the note -- an rtf file -- is actually an RTFD, which is a package. I think it's locking the package folder, which is the parent of the file trying to be removed...

rtf - rtfd
 

So it would be interesting to see if SuperDuper! also would stop if the locked file is just a .rtf as opposed to, in my case, a .rtfd.

I'll try that...

Sincerely, Martin.

Yes. I think you'll find it doesn't stop.

Locked .rtf will copy
 

Dave, I confirm. Locked .rtf files will smart update. So SuperDuper! can delete them on the target drive and it will copy them over from the original drive if the original has a more recent modification date.

In contrary, any file, even without pictures, which I create inside iNotePad gets saved as .rtfd. Those locked .rtfd files cannot be deleted on the target drive and therefore make SuperDuper! unexpectedly stop.


Sincerely, Martin.

Yep. That's the bug I've got logged. Thanks.

Still trouble with locked files?
 

Add locked files ending .xml and .wav. Both stopped SD with the error mentioned above.

I don't think so, at least not any more: I've tested locked files and they work fine. Are you certain? Is it when the files are deleted?

Basically, I know of no problem like this in the current version. Note that locked symlinks -- one of those things that can't be done in Unix, but can with Finder -- can cause issues, but we have that logged and fixed internally. But this doesn't sound like that case...

Here's what I've tried:

• Create a file (various types, including XML, but that doesn't matter)
• Lock in Finder
• Copy to a destination
• Smart Update (no problem - no changes)
• Unlocked file and modified
• Smart Update (no problem, copy unlocked)
• Locked file
• Smart Update (no problem, copy locked)
• Unlocked file, modified, re-locked
• Smart Update (no problem, modified file copied, locked)