Couple of strange things after superduper
 

I have three disks. Internal #1, internal #2 and external FW #3.

I use #2 & #3 as clone/backups of #1.

After doing smart backups

#1 -> #2
#1 -> #3

I have noticed a some strange things.

A - When I try to trash something on #2 or #3 I get a warning that it will be deleted immediately instead of it simply going into the trash.

B - Some of my applescripts that are scheduled via the Macaroni Prefs pane hang the first time they run.

I solve A by rebooting. Note, I have to reboot twice since my wireless mouse doesn't respond after the first boot.

Any thoughts on this?

We've had a report of A before, Robert, and we're trying to figure out what's going on. I think it might have to do with the fact that the .Trashes, from the root, isn't copied, and since it's not there OSX gets confused until the next reboot, when it's created again.

To test this theory on your system, try the following:

- Choose File | New Copy Script in SuperDuper!
- Enter a quick description, which will be displayed in the "What's going to happen?" section of the main window
- In the 2nd tab, include "Backup - all files"
- In the 3rd, locate .Trashes in the first box, and click "Add". Then, change the command to "copy"

Save this with a reasonable name, and choose it instead of "Backup - all files" in the 3rd pop-up of the main window. Then, run the backup again and let me know what happens.

Regarding Macaroni -- I really don't know why that would happen. What do these scripts do? Can you tell if they're running at all? We're not doing anything funny at all to scripting, and don't modify the main volume (save for our log and preferences), so I can't see how this might be due to SuperDuper!

(It's possible that the additional applications, present on the backup volume -- and thus in the LaunchServices cache -- confuse something about the scripts you're running, though.)

Marcaroni is nothing but a scheduler. The applescripts it launches are daily backups of directories containing files I modify daily. The applescript all look like this

duplicate folder "Bobs_G4-1:Users:robert:Documents:" to folder "Bobs_G4-2:Users:robert:" replacing yes

The applescript usually hangs with a message to the effect that the file already exists which should not happen since it specifies replacing yes

I'll try your experiment later and advise.

I'm really not sure why those AppleScript calls might hang, and can only point to a potential problem with AppleScript itself: unlike the other issue, which could be affected by the missing .Trashes folder, we're using standard calls to copy the files, and there's no reason I can think of why that would affect AppleScript, except by triggering a latent problem.

Is this under Jaguar, Panther or Tiger?