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 because Sigil's built in unzip library is "stupid", Sigil should be fine even if dirhelper runs and removes temp files. These files would be candidates for being deleted out from under the application that created them in temp when dirhelper is launched. 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). So even if dirhelper runs, nothing Sigil related will be older than 3 days and so should not be deleted out from under Sigil. This is because the unzip utility used inside of Sigil does not know how to unpack or set unix file date/time information. 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. date of creation of the file (not typically available on Linux) Please check that plist and let me know what it says and if your data losses happened near the time set in that plist according to your computers clock, so we can rule this out.Ĭode: stat `find $TMPDIR -name "*"` | grep SigilThe dates you see for the Sigil temp files are in this order (on Mac) It has never hit me, but my clock is correct and I simply do not use Sigil at 3:35am so I have not seen the issue. Not sure the best way to deal with this since lots of Sigil files are unzipped in the correct temp directory to remove issues with attacking temp files creation using races. Related Office bug reports on el capitan can be found here: Why this bug hits El Capitan again is beyond me? So please verify your system clock and the time for dirhelper to run from that plist file to rule out any nonsense caused by this strange policy by Apple. The file that determines dirhelper's time of launch is: For the bug to hit, it must be 3:35am and the dirhelper daemon is run and you have unmodified files unpacked from a zip by the os that uses the zip extended date information to set the original file date. This is unheard of behaviour that only impacts software that unzips possibly old files inside the correct temp directory such as Sigil and Office do. Notice in that issue when it says if you unzip an archive with files that have a modification date of over 3 days old, dirhelper may simply delete them when it runs!!! Here is an official apple discussion about this nonsense when it hit under Leopard. on Mac OS X, there is a dirhelper daemon that looks for files not accessed within 3 days inside the official temp directory and will delete them even if the app using them is still running. There are a number of bug reports about temp files mysteriously being deleted on Mac OSX el capitan creating issues for Office that uses.
0 Comments
Leave a Reply. |