Sigil 1.1.0 "losing" files

[DiapDealer]

Originally Posted by snarkophilus

Currently the temp folder is set to <SIGIL_DEFAULT_TEMP_HOME>.

I think for now I'll set my Sigil temp folder outside ...\AppData\Local\Temp and see if this problem goes away after my patch reboot.

For the record, The <SIGIL_DEFAULT_TEMP_HOME> is AppData\Local\Temp. We just obscure it a bit with that placeholder to discourage people from messing with files in that location while Sigil is running. For some strange reason, many new users seemed to think that noodling around in Sigil's scratch directory was a good idea.

[snarkophilus]

Originally Posted by DiapDealer

For the record, The <SIGIL_DEFAULT_TEMP_HOME> is AppData\Local\Temp. We just obscure it a bit with that placeholder to discourage people from messing with files in that location while Sigil is running. For some strange reason, many new users seemed to think that noodling around in Sigil's scratch directory was a good idea.

Yeah, I figured that out. I knew about the AppData location before I knew of the config option. Ya know, noodling around .

In the "don't try this at home, kids ... but what the heck, you only live once" section, if I

unzip -n /path/to/last/epub-with/images
rm mimetime

(-n doesn't overwrite existing files, and it looks like Sigil automatically adds a mimetype when saving) then press the "Save" button in Sigil, lo and behold I get my epub back with all the missing bits with the correct structure, passes EPUBCheck and looks peachy good.

[BetterRed]

Originally Posted by snarkophilus

Oh, the idea that Windows could have done this behind my back is ... worrying.

Dig, dig, dig ...

Well bugger? This link on the MS community forum talks about auto-cleanup. As per the attached screenshot, I do have this Storage Sense option enabled, but it shouldn't have touched anything less than 30 days old. Going from some of my old backups of this epub, it looks like the timestamps on the images gets updated each save (part of the zipping process?).

Currently the temp folder is set to <SIGIL_DEFAULT_TEMP_HOME>.

I think for now I'll set my Sigil temp folder outside ...\AppData\Local\Temp and see if this problem goes away after my patch reboot.

Well blow me down with a feather, I was right!

Just checked my Storage Sense it's disabled (like me). Windows must have set it that way because I didn't even know it existed until now, unless I saw it somewhere and absorbed it subconsciously - Donny would call it known unknown.

"Delete temporary files that my apps aren’t using" - how would it know which files an app is 'using' if the app is not holding a handle for the file. I don't have my hands on my Loo Paper roll right now, but I'd be pissed off if someone took it - I'm down to my last 62 rolls

BR

[DiapDealer]

Originally Posted by BetterRed

"Delete temporary files that my apps aren’t using" - how would it know which files an app is 'using' if the app is not holding a handle for the file.

That's my question, too. If left open for a really long time, is Sigil still "using" the container.xml file? The META-INF folder? If no image tabs are open or being rendered in Preview, are the images being used? I would hope something like that would be handled based on the open temp folder handle and not the individual files in it. But it IS Windows. They don't always make the wisest decisions.

[hobnail]

Originally Posted by BetterRed

IMO temp folders (user and system) belong to Windows. MS may have smuggled in a 'Dynamic cleanup of temporary folders based on Last Used date' feature into a Windows patch release and forgot to tell anyone.
BR

I once lost a bunch of files that were in a folder in the temp directory where I was doing some 3d renders. I have a 2nd drive and have my temp folder set to d:\tmp and had the 3d stuff in a folder in that. After windows silently "cleaned up" old stuff in it I renamed the render folder to d:\render.