Bug: Report Split Unsaved Filesize

[Tex2002ans]

See attached EPUB.

I copied/pasted 2 lorem ipsums and added a split marker in the halfway point.

Version: Sigil 0.9.13
OS: Windows 10 (1809)

Steps to Reproduce Bug

1. Tools > Reports > HTML Files. You should see Part1.xhtml as ~63 KBs.

2. Go back to Code View and Split at Markers (F6).

3. Refresh the Report.

You'll see Part1.xhtml is ~63 KBs while Part1_0001.xhtml is .01 KBs.

Expected to see both files ~31.5 KBs.

After saving and run/refresh the report again, the file size adjusts fine.

PS. Never ran across this before because I constantly press Ctrl+S like a fiend, so never have unsaved EPUBs. :P

[DiapDealer]

I seriously never expected that so many people would leave the reports dialog open while making changes to the underlying files. It's too late to change it now, of course, but if I had my way, Reports would be a modal widget. But alas ...

... we'll look into it.

[KevinH]

Yes the report feature is directly tied to the state of the files on the disk when the report was first generated.

So the split happened and both tabs are correct. If need be verify that by opening the new tab in a CodeView tab. The new file contents are not actually written to the disk until it actually needs to be. In other words, not until a save is done, a plugin is run, etc.

This is how Sigil has always worked, otherwise opening up large epubs would be even more time consuming than they are now. The contents of the files are held in Resource Widget caches and only written to disk when needed. For speed these disk files before updating are often just placeholder text.


This is done to speed up loading of files and other things, as writing to disk can be slow

[KevinH]

We could modify the refresh tab on Reports to flush all caches to disk at the expense of speed.

[Tex2002ans]

Originally Posted by DiapDealer

I seriously never expected that so many people would leave the reports dialog open while making changes to the underlying files.

I was working on a book with an extra large chapter (~440 KBs) that I wanted to split + I wanted to make sure I chose a subheading that was ~halfway filesize.

[KevinH]

To "fix" this, in MainWindow in "ReportsDialog()" we would have to do the following immediately after the call to SaveTabData() to force everything to disk.

    m_Book->GetFolderKeeper()->SuspendWatchingResources();
    m_Book->SaveAllResourcesToDisk();
    m_Book->GetFolderKeeper()->ResumeWatchingResources();

This will take the time to force all changes to be actually written back to the disk.

[KevinH]

I am going to add this in because if we bother to collect file size info, it should be correct.
I will push this fix to master.

Thank you for your bug report!

KevinH

ps: just pushed. This fix will be in the next release.