Recovered Files folder in Trash

[Cuneyt]

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]

Have you crashed or shut down improperly recently?

[Cuneyt]

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]

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]

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]

FYI,

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

[dnanian]

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

[Cuneyt]

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

[dnanian]

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

[Cuneyt]

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]

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]

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]

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]

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]

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

[dnanian]

Well, part of the problem there is that the folder is /var/tmp, not /vat/tmp. The script is not being run as you, but rather authenticated as root.

I'm not sure I would bother with this, Herbert. The 322 is likely to change (since it's probably a random number of sorts), and if it's just a matter of emptying your trash every so often, it seems unnecessary.

[Cuneyt]

If I run the following little applescript after the SuperDuper!, the problem goes away.

set osx_path to (path to temporary items folder as string)
set unix_path to POSIX path of osx_path
do shell script (("cd " & quoted form of unix_path & " && rm -rf *") as text)

[dnanian]

Um, that could easily remove things that other applications are depending on...

[Cuneyt]

Um, that could easily remove things that other applications are depending on...

Yes, but this is the last thing that I do just before the shutting down the system. :)

[dnanian]

OK, but just so others don't do this without thinking about it carefully-- it might be better to just empty your trash every so often.

[Cuneyt]

OK, but just so others don't do this without thinking about it carefully-- it might be better to just empty your trash every so often.

Agree, it's easier than running a script. :)

[macfeller]

I'm getting them files, too, after every SmartUpdate.

[dnanian]

Yes; everyone will...

[Timmy]

Yes; everyone will...


Does it just pertain to Smart Updates with 2.1?

I am only seeing the issue on 10.4.5 but not on 10.3.9 (but I don't use Smart Update on the Panther system...)

-Timmy

[dnanian]

10.3.9 doesn't "clean up" the /tmp folder the same way, so you wouldn't see the issue there. The problem is a combination of the eSellerate "Embedded Web Store" engine installing itself when we run (and not cleaning up its temporary files), and Tiger's behavior that moves folders in the user's /tmp folder to "Recovered Files" in the trash.

Again, this isn't a huge deal (although it's annoying); you need only empty your trash normally -- when you do so, these files will be removed.

[minckster]

There's a similar discussion in the Flip4Mac forums. That discussion centers on conflicts between the version of eSellerate used by different apps. User "MyBFDoesTheHousework" appears to have a larger problem than files piling up in her trash, but that must be rare.

Perhaps the developers of SuperDuper! and Flip4Mac should compare notes.

Link: http://www.flip4mac.com/fusetalk/forum/messageview.aspx?catid=26&threadid=1114&enterthread=y

[dnanian]

We're pretty sure we know what's going on, but unfortunately can't fix it directly -- we can only work around the problem (which we're doing), at least until eSellerate releases a fix in their code.

[gggrish]

We're pretty sure we know what's going on, but unfortunately can't fix it directly

Isn't it a valid reason to stop installing this framework? I don't want this on my system because:


you never told me about it, fortunately the Trash spilled the beans! :D
AFAIK it's completely useless, I don't need a framework to buy your software :eek:
if it's an annoyance to users it could make you look bad :o

[dnanian]

Actually, it's listed in the "What does SuperDuper! install" FAQ.

The next version of SuperDuper! will only install the framework if you click "Buy Now!" inside the application.

Note, though -- having a framework present does *nothing* to destabilize the system or do anything else untoward. We're not replacing a system framework -- it's just that eSellerate is used by a lot of different programs, and thus they install to /Library so that all applications that use the eSellerate Web Store can share the same code.

[sdsl]

This is really a non-issue. Mac OS 10.4 puts leftover temporary files in the trash upon startup, from time to time, even on systems where SuperDuper is not installed. It's normal behavior for the OS. See for instance,

http://docs.info.apple.com/article.html?artnum=301913

and

http://www.macfixitforums.com/php/showflat.php?Cat=&Board=tiger&Number=753621&page=0&view=collapsed&sb=7&o=31&fpart=1

Apple's recommendation (see above Knowledge Base article) is "Don't worry," these files can be "safely deleted."

People with a lot of time on their hands can write scripts and the like for this. For me, the File => Empty Trash command seems about as easy as it gets. If this is what folks have to post about in this forum, well then I'd say that reflects pretty highly on Tiger's and SuperDuper's reliability that this is all that's left to complain about.