Sigil-Ebook/Sigil

[Bug]: "The Nav document can not be removed." after moving nav to other file

Closed this issue · 2 comments

YodaDaCoda commented

Bug Description

I'm editing an epub3 with a nav.xml file. The epub contains a separate toc, so I'm merging the two by moving the <nav> into the toc file. After doing this, updating the opf to match, and saving the file, I expect to be able to delete the now-empty nav.xml file.

If I close and re-open the file with Sigil, I then get an error "Files exist in epub that are not listed in the manifest, they will be ignored". Then I have to use a zip editor to delete the nav.xml file.

Workaround: If I close and re-open the epub with Sigil, without removing the nav from the opf, but removing its nav property, I can then delete the nav.xml.

Platform (OS)

Windows (Default)

OS Version / Specifics

win11

What version of Sigil are you using?

2.0.2

Any backtraces or crash reports

No response

kevinhendricks commented

Yes just like trying to delete the ncx under epub2, Sigil will not allow you to delete required files. You could of course just merge the toc.xhtml into the nav and delete the toc.xhtml using Sigil's menus.

You can also rename the nav if you like. And yes the nav property in the opf manifest is what is used to identify the nav to Sigil.

If you move, the nav property in the opf manifest to another file first, and if Sigil can detect that change it might be able to update itself properly allowing a delete. I will look into it.

kevinhendricks commented

Actually, I just double checked and this code parallels exactly how Sigil treats the ncx under epub2. The ncx resource was set once when the epub2 was loaded, and the nav resource was set once when the epub3 is loaded. And neither can be deleted using Sigil's tools.

Given you can always copy and paste anything into the nav document from any other xhtml document, and can rename it at will. There is no need to actually delete the active nav for any reason.

So this code works as designed and exactly parallels the ncx under epub2 since both serve the same role.

So not a bug. And not something that should be changed.

Sorry.