I ran some tests to see what modification dates are set for epubs "unzipped" on Sigil as follows (this is under Mac OS X 10.10 not 10.11) (it should work similarly under Linux).
1. Open Sigil.app and then open any old epub you have around that you have not touched yet today
2. In Terminal.app type the following command:
Code:
stat `find $TMPDIR -name "*"` | grep Sigil
The dates you see for the Sigil temp files are in this order (on Mac)
- date last accessed
- date last modified
- date the last file inode was changed
- date of creation of the file (not typically available on Linux)
When I run this test on Mac OS X Yosemite I can see that each and every file access, modification, inode change and birth date are today's date. This is because the unzip utility used inside of Sigil does not know how to unpack or set unix file date/time information.
So even if dirhelper runs, nothing Sigil related will be older than 3 days and so should not be deleted out from under Sigil.
If I instead cd into $TMPDIR and create my own dir there and run the command line unzip on the epub, it is smart enough to unpack old dates and properly set access, modified, and birthed and so temp may very well end up with files "older" than 3 days even though they were just created (unzipped). These files would be candidates for being deleted out from under the application that created them in temp when dirhelper is launched.
So because Sigil's built in unzip library is "stupid", Sigil should be fine even if dirhelper runs and removes temp files.
I would love to see a similar test run on El Capitan (Mac OS X 10.11) to see how it handles things to verify that this is not the source of your issues. So if anyone has El Captian and would try this, I would appreciate knowing if any of the dates shown are older than 3 days when using Sigil to edit an epub.
Thanks,
KevinH