Quote:
Originally Posted by KevinH
... The actual epub is opened into a temp area (with all files copied in) and Sigil processes it from there. Saving a file or save-as takes those files and recreates the epub. It does not replace members in the existing epub it only overwrites the epub file. So file modification dates in the epub/zip are meaningless.
To track changes you will either need to use Sigil's checkpoints and in its diff capability, or git or possibly effectively do what github does and hash/checksum each file to see which are changed in the zip from a prior version to know what changed outside of Sigil.
|
That modification dates inside a zip file, or specifically epub, are not useful, I strongly disagree. Of that too, maybe little I say will have an effect for the moment, but I ask to merely think of it and I hope someday such really changes. That dates are not kept really prevents me from continued use of Sigil with one specific EPUB. After initial creation or modification, I use instead BBEdit so I can keep track of mod dates, as for other reasons.
If Git or some other similar software is better suited to tracking changes, that could be. Myself, I merely use the version history from some cloud storage to revert any unwanted changes. As for modification dates, for example, how many commercial EPUBs many of us have, and use Sigil for some common mods such as fixing typos, editing the TOC, or other. Often, I may just restructure to Sigil norm, rename the files, edit the TOC, etc. In such cases, maybe I could note such, but it is much easier to just keep the mod dates. So for example, if images or certain files are not modified, many years later I can see the original dates of the EPUB files for those not modified. Or if the image mod dates are modified, I may know if did something to them such as compress. Or if I add a font, I can know the mod date of the font compared to the copy of it I have elsewhere. There are possibly many reasons why keeping each and every EPUB elsewhere such as in Git is to me impractical.
In the case of commercial EPUBs, as publishers may later re-publish with corrections, I can easily compare the date, know when the EPUB was made from mod dates, and then if there's an update, know that it is an update from the dates, and possibly compare or replace if needed.
Maybe there are other cases. To me, not changing the mod date of a file if it's not modified is a given and what should be done. Yet I understand others at the moment disagree. Zip files, archives in general, backup, and so forth, whatever, for the file system itself, mod dates I consider important.
I do not really know C++, and particularly I have not tried to look at the Sigil code, yet I may start and continue. I think this is the place where mod dates are set?
https://github.com/Sigil-Ebook/Sigil...tEPUB.cpp#L174
I am not familiar with that particular parameter, and if it contains info other than moddate. I tried to look at API docs, yet couldn't find much description of that parameter yet. Is passing null enough? Yet I am also not familiar with the rest of Sigil. Perhaps file modification state is not kept, or maybe it is. After the EPUB is unarchved to a temp folder, perhaps merely saving any files if needed, and not modifying others is enough. Or maybe more is required so that is part of the resistance to such change. I don't know. I just hope someday. If I were to attempt it myself, are there other larger changes needed?
We have at least one other that finds such useful.