Recovered Files folder in Trash
 

I notice that I am having a Recovered Files folder in Trash, contains:

3225137678 (folder)
EWSMac.framework (folder with some stuff in it)
EWSMacCompress.tar.gz (file)

after making a copy with SuperDuper! and startup.

If I startup without running SuperDuper!, there's no Recovered Files folder in Trash. There's also an EWSMac.framework folder in Library/Frameworks/, but not the EWSMacCompress.tar.gz file. I searched for it and it was in SuperDuper!.app/Contents/Resources/ so it's related with SuperDuper! and this problem started with version 2.1.

Have you crashed or shut down improperly recently?

No, I haven't. I also checked the disk with DiskUtility and found no problems. It started with SuperDuper! 2.1.

I got the same files in Trash after using SuperDuper 2.1 v77.
According to system.log, SDCopy crashed while running SuperDuper!, before restarting my iBook.

Well, those particular files are part of eSellerate's purchasing engine, and are installed when we go through registration, by their own code.

I don't know why they'd be in recovered files, since that's for files that were "fixed" by Disk Utility/fsck during scaning after a crash, but eSellerate has come out with a new version of their library, which we'll be including in our next update. Perhaps it'll be fixed in that.

FYI,

I noticed that the 3225137678 (folder) was in /private/var/tmp/folders.504/TemporaryItems/ after SuperDuper! copy.

Yes, the eSellerate library is checking itself, and creates a temporary file there.

... and eSellerate library is forgetting to delete them after checking, I suppose.

That's right, although that doesn't really explain why it ends up in "Recovered Files".

Once, I've written a script which was creating a temp file path to temporary items folder. I remember that if I don't delete that file at the end of the script, that file was in the Recovered Files folder on next startup. For this purpose I added a line that deletes the temp file at the end. Problem was gone. I suppose, it is something like that.

That's weird. I wonder why they do that with /tmp... things create stuff in /tmp all the time without deleting them (although they should), but maybe they treat folders specially.

You're right. While I was writing that script I was told that to create the temp file path to temporary items folder and it won't be needed to delete manually, OS X would delete it automatically on next startup. But, I noticed that it was not the case. May be something changed in OS X recently. Then I had to delete it at the end of the script. I suppose, OS X moves them into Recovered Files folder on startup if it find anything in the TemporaryItems folder considering as they were remained undeleted in the previous session. Just a thought.

Howdy,

I've seen this behavior ever since I went from 10.3 to 10.4. I think the system ``told'' apps to make their temp files in /private/tmp/ (link was /tmp/) but now it's in /var/tmp/folder.UID/Temporary Items/ and we have this wonderful behavior that fills our trash. Sigh... ;-(.

Good Luck,
Herb Schulz

Exactly, Herb. We've reported the problem to eSellerate, and we have a potential workaround for the next version of SuperDuper, too. (Unfortunately, it involves not compressing the framework, but that's better than nothing.)

Howdy,

I run a script at the end of the SuperDuper run that turns off Spotlight Indexing on the clone*. If I add a line to

rm -fr /vat/tmp/folder.MyUID/TemporaryItems/322*

the folders/files don't seem to get removed. Is that script being run as ``me'' or some other user (su)? Is the Esellerate stuff being written after the script is run?

I'm not really comfortable trying to remove those 322* directories since I don't know if something like that would be created by some other application but generally I'm not running anything else (at least regular apps) while SuperDuper is running.

Good Luck,
Herb Schulz