Shirt Pocket Discussions

Shirt Pocket Discussions (http://www.shirt-pocket.com/forums/index.php)
-   General (http://www.shirt-pocket.com/forums/forumdisplay.php?f=6)
-   -   Recovered Files folder in Trash (http://www.shirt-pocket.com/forums/showthread.php?t=1141)

Cuneyt 03-13-2006 05:09 PM

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.

dnanian 03-13-2006 05:24 PM

Have you crashed or shut down improperly recently?

Cuneyt 03-14-2006 01:45 AM

Quote:

Originally Posted by dnanian
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.

rhatta 03-14-2006 03:56 AM

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.

dnanian 03-14-2006 08:46 AM

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.

Cuneyt 03-15-2006 06:12 PM

FYI,

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

dnanian 03-15-2006 06:17 PM

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

Cuneyt 03-16-2006 01:45 AM

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

dnanian 03-16-2006 08:30 AM

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

Cuneyt 03-16-2006 08:39 AM

Quote:

Originally Posted by dnanian
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.

dnanian 03-16-2006 08:59 AM

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.

Cuneyt 03-16-2006 09:07 AM

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.

Herbert Schulz 03-17-2006 09:41 AM

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

dnanian 03-17-2006 09:49 AM

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.)

Herbert Schulz 03-17-2006 11:48 AM

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


All times are GMT -4. The time now is 01:42 AM.

Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.