Calibre Temp folders, yet again

[drMerry]

Originally Posted by kovidgoyal

On windows calibre leaves behind a few zero byte files. It's because of windows file locking. Either I have calibre wait for all worker process to shutdown and release the locks on their log files, which can take a while, making shutdown/restart times slow or I leave behind some zero byte files. I choose the latter.

I had hundereds of files. This is a problem when you run CCleaner. It takes ages to index all those 0b files.
But I have an other option.
Is it possible to add (1 of this) option(s):
1. A funciton like test db (clear temp files)
2. A clean-up interval setting (clean calibre every 2 files)
3. A clean-up function on update

[Starson17]

Originally Posted by drMerry

I had hundereds of files. This is a problem when you run CCleaner. It takes ages to index all those 0b files.
But I have an other option.
Is it possible to add (1 of this) option(s):
1. A funciton like test db (clear temp files)
2. A clean-up interval setting (clean calibre every 2 files)
3. A clean-up function on update

My solution:

I launch calibre in a Windows shell from a batch file using calibre-debug -g.
Before launching, I set the temp folder(s) for that shell session so that all Calibre temp files go into the same temp folder. I delete the temp folder both before and after the shell session.

[kovidgoyal]

The zero byte files problem on windows was fixed many versions ago. As long as you quit calibre cleanly, there should be no temp files left.

I just tried it on win7 and saw no temp files being left behind.

[Starson17]

Originally Posted by kovidgoyal

The zero byte files problem on windows was fixed many versions ago.

For the record, my "solution" is from a time long prior to this fix. When the zero byte files problem was fixed, I didn't bother to undo my solution because:
1) I don't always exit cleanly, and
2) I had excluded my Calibre-specific temp folders from antivirus monitoring, but didn't want to do that to the real temp folders.

Neither would be a sufficient reason for me to set it up now.

[jackie_w]

Originally Posted by kovidgoyal

The zero byte files problem on windows was fixed many versions ago. As long as you quit calibre cleanly, there should be no temp files left.

I just tried it on win7 and saw no temp files being left behind.

FYI - I just tried opening and closing calibre 7.59 on my WinXP machine.

I still get 2 zero-length calx.tmp files which are not deleted. I also have 2 non-empty directories which are not deleted: gen_py and fontconfig.

In addition, if I do a Ctrl-R to restart calibre I also get a 3rd directory containing a subdirectory of what looks like my 3 news recipes (which I rarely use). This doesn't get deleted when closing down either.

[theducks]

My XP Temp dir listing:

Spoiler:

Volume in drive C is C-clamp

Volume Serial Number is F857-3467



Directory of C:\Documents and Settings\shop1\Local Settings\Temp



05/05/2011 09:30 <DIR> .

05/05/2011 09:30 <DIR> ..

04/29/2011 03:27 1,510 AUCHECK_CORE.txt

04/29/2011 03:27 370 AUCHECK_PARSER.txt

04/28/2011 12:34 0 cal31.tmp

04/28/2011 12:34 0 cal32.tmp

04/30/2011 13:38 0 cal33.tmp

04/30/2011 13:38 0 cal34.tmp

04/28/2011 15:39 0 cal47.tmp

04/28/2011 15:39 0 cal48.tmp

04/30/2011 21:27 9,943 cal49.tmp

04/30/2011 16:47 0 cal4A.tmp

05/01/2011 14:47 0 cal4B.tmp

05/01/2011 14:47 0 cal4C.tmp

05/02/2011 07:16 0 cal4D.tmp

05/02/2011 07:16 0 cal50.tmp

05/03/2011 08:13 71 cal51.tmp

05/02/2011 08:11 0 cal52.tmp

05/04/2011 17:28 0 cal53.tmp

05/04/2011 17:28 0 cal54.tmp

04/28/2011 22:28 0 cal63.tmp

04/28/2011 22:34 301 cal64.tmp

04/28/2011 22:36 0 cal65.tmp

04/28/2011 22:36 0 cal68.tmp

05/03/2011 08:13 0 cal86.tmp

05/03/2011 08:13 0 cal87.tmp

05/03/2011 08:15 0 cal88.tmp

05/03/2011 08:15 0 cal89.tmp

04/29/2011 13:26 0 cal9C.tmp

04/29/2011 13:26 0 cal9D.tmp

04/29/2011 15:52 0 calBB.tmp

04/29/2011 15:52 0 calBC.tmp

05/05/2011 06:49 <DIR> calibre_0.7.56_tmp_yhkw0f

05/02/2011 18:26 <DIR> calibre_0.7.59_tmp_9m7iim

05/05/2011 06:49 <DIR> calibre_0.7.59_tmp_bvm_r2

05/04/2011 19:21 <DIR> calibre_0.7.59_tmp_hgh6sc

05/05/2011 09:30 0 foo.txt

04/05/2011 08:01 <DIR> gen_py

31 File(s) 12,195 bytes

7 Dir(s) 15,977,869,312 bytes free

[kovidgoyal]

gen_py and fontconfig are created once and not recreated each time calibre is restarted. In other words you will not have more than one of those. I'm interested in temp files that multiply with each calibre restart.


The cal(whatever).tmp files are news to me. I'll have to look into what is creating them. All temp files created by calibre itself (as opposed to those created by libraries/programs calibre uses) should be in the calibre_0.7.59_something directory, which is deleted on exit.

[kovidgoyal]

Ah, I think I know what is causing the cal(whatever).tmp files. I always start calibre as

calibre-debug -g

which does not create those files, it's a normal invocation of calibre that does. Fix will be in the next release.

[theducks]

All exits are not by choice (conventional exit)

I see at least 1 Dr Watson a week (usually a Qt...).
Nothing I know enough about to turn the crash into a Bug report

[jackie_w]

Originally Posted by kovidgoyal

All temp files created by calibre itself (as opposed to those created by libraries/programs calibre uses) should be in the calibre_0.7.59_something directory, which is deleted on exit.

The recipes directory which is not being deleted has a variable name e.g. calibre_0.7.59_tmp_nmzrru. The subdirectory for this one was called calibre_0.7.59_dv_jkj_recipes

This seems to be created by calibre as it starts. If I do a normal exit the dir is deleted. If I do a Ctrl-R a second calibre_0.7.59_tmp_x directory is created. On normal exit only one of them is deleted. So there can be a build-up if you do lots of restarts. Probably not common practice, but I noticed it when I was doing a lot of work editing my plugin.

[kovidgoyal]

@jackie_w: Thanks, good catch, I'll look into fixing that as well.

[kovidgoyal]

I've committed fixes for both the cal(whatever).tmp files and the restart bugs.

[drMerry]

And again a lesson learned.
Use a second pc without debug start

Thank you for fixing this in this short time!
Great!