Image editing creates unmanifested images

[KevinH]

Fwiw, someone could create a plugin specific to IrFanView that uses the currently selected file info and launches it and writes the file changes back properly via the plugin without having to worry about _org files.

[KevinH]

Or perhaps we create an unmanifested file additional Report?

[DiapDealer]

Originally Posted by KevinH

Or perhaps we create an unmanifested file additional Report?

That would probably be easy enough.

I've never really delved very deeply into the OpenWith code, so I have no idea what would be involved, but it doesn't seem to me that it would be impossible to employ an approach that:

1) copied the file in question to a new temp folder and opened that file in the external editor
2) after the editing is complete, copy ONLY the original filename back to the epub's scratch directory.

Checks could of course be made to determine whether the file was changed or not, and if the original file name is no longer present in the staging temp location (like with an unwise rename), a warning could be popped that nothing is being changed.

Just spit-balling, really. I just don't want to introduce anything into the Open With code that would require any kind of parsing/modification of the EPUB's manifest. File out ... same file name back in.

[AlanHK]

Originally Posted by Doitsu

When you save and reopen the file, Sigil will ignore all unmanifested files and you'll no longer get EpubCheck error messages, because unmanifested backup files won't be copied to the temp folder of the book.
However, they'll remain in the epub until you save it again with Sigil at which time they'll gone for good.

OK.
Yes.

test: a.epub 237 KB

1) Use "Open with" calling an app that creates backups.
now 288 kB

2) save file -- the backups are in the archive, but not the manifest.
still 288 kB

3) exit
288 kB

4) re-open file -- backups are still there
288 kB

5) save -- backups are gone
211kB


When testing this I stopped first at step 2, then 4. You have to get to 5 before Sigil finally recreates the epub and cleans house.

So as long as such external edits are not the very final thing you do, the unmanifested backups will be discarded.


So I don't have to audit every epub I've edited for the last year. What a relief.

[KevinH]

I like this idea as it is much safer in general. When I get a free moment, I will see if it is an easy modification.

Originally Posted by DiapDealer

That would probably be easy enough.

I've never really delved very deeply into the OpenWith code, so I have no idea what would be involved, but it doesn't seem to me that it would be impossible to employ an approach that:

1) copied the file in question to a new temp folder and opened that file in the external editor
2) after the editing is complete, copy ONLY the original filename back to the epub's scratch directory.

Checks could of course be made to determine whether the file was changed or not, and if the original file name is no longer present in the staging temp location (like with an unwise rename), a warning could be popped that nothing is being changed.

Just spit-balling, really. I just don't want to introduce anything into the Open With code that would require any kind of parsing/modification of the EPUB's manifest. File out ... same file name back in.

[KevinH]

Found OpenExternally.cpp in Misc. The problem is it uses Qt signals on watched files to know when to update (ie that the application you used with openwith has written something) and uses QProcess startDetached so that the appliction just opened can work in parallel with Sigil allowing full use of the Sigil gui simultaneously.

Since the new process starts in a detached state, no process are done queries or status calls are easily available. We would have to create a new thread to watch a copy of the file being operated on in its new temp location and then write that file back into the correct place where Sigil wants it.

Thus having openwith work directly on the files inside Sigil is much easier/simpler than having to create an additional thread. So the proposed change is not easy unless we create a new watched file pool and figure out how to translate changes in the new temp location to changes in the corresponding internal Sigil file.

It would probably be easier to replace IrFanView with a script that launches IrFanView on the true Sigil location and then cleans up after itself after IrFanView completes.

I still need to check if remove unused images and/or the reports can be used to detect the unwanted files and remove them. Altenatively, a "Remove Unmanifested Files" tool might be generally more useful.

[AlanHK]

Originally Posted by KevinH

It would probably be easier to replace IrFanView with a script that launches IrFanView on the true Sigil location and then cleans up after itself after IrFanView completes.

That would require the user to know about this issue so he'd use this script. My post was prompted by the fact that the files are invisible in the GUI, only shown by an increase in filesize.

But as I mentioned above, it isn't just Irfanview; any program that creates backups, or anything else in the same folder, will result in these files being included in the epub. Many text editors used on the html also will do this, for instance.

However, it seems that closing, then reopening the epub, making any edit, then saving, will lose all the unmanifested files. So they are discarded as long as you do some normal edits within Sigil after the "open with" ones. Or even just prettify the files.

[DiapDealer]

Thanks for looking Kevin. That kind of complication is exactly what I wanted to avoid. Most programs that create automatic backups give the user the opportunity to turn them off. It's unfortunate that this Irfanview plugin doesn't, but I can't get that worked up about it (because it's not Irfanview itself that's the problem). It sounds like the plugin dev is amenable to requested changes, though. Perhaps that's the best route forward.

[BetterRed]

Originally Posted by KevinH

I still need to check if remove unused images and/or the reports can be used to detect the unwanted files and remove them. Altenatively, a "Remove Unmanifested Files" tool might be generally more useful.

Rather than a tool, or as well as a tool, have a checkbox setting : Preferences->General->Remove Unmanifested Files on Exit - checked by default, with a Remove Yes/No? if any are found.

BR

[KevinH]

Could be done on Save or Save-As in Sigil but not on exit from the Application opened via OpenWith as I tried to explain as those are separate detached processes and nothing in Sigil is waiting for it to close (ie blocking) once started or checking its status.

[BetterRed]

Originally Posted by KevinH

Could be done on Save or Save-As in Sigil but not on exit from the Application opened via OpenWith as I tried to explain as those are separate detached processes and nothing in Sigil is waiting for it to close (ie blocking) once started or checking its status.

Why did I write on Exit when I was thinking of Save - a'la Mend on Save?

My first thought was to fold it into Mend on Save, but decided it would be better to keep them separate; having just cursed MS for combining the settings for two Windows features I regard as chalk and cheese.

BR