bug in ebook-viewer: the file is modified

[tigran]

I found a very serious bug in the ebook-viewer utility --- after running it on an epub the file is modified --- even the file size changes. Obviously, this should NOT happen because a viewer is not supposed to change anything inside the file.

Interestingly, it only happens if the file's permissions allow write. I.e. if I run "chmod 0400 file.epub" before executing "ebook-viewer file.epub" then the file is not modified.

The version of calibre I am using is 2.18 on Linux x86_64 architecture.

Please confirm that this can only happen with ebook-viewer, but not ebook-meta. I can simply remove ebook-viewer from my system as unsafe, but ebook-meta is a mission-critical utility as I am relying on it for metadata extraction for most formats (for some formats I wrote a better metadata and cover extractor myself, e.g. for djvu and fb2)

[davidfor]

"It's not a bug, it's a feature." It really is.

The viewer stores the reading position and any bookmarks in the epub. The viewer has an option to turn this off, but it doesn't remember were you were up to.

[drjenkins]

Open a book in the Viewer and click on "Preferences". Select the "General" tab and "Miscellaneous options". Uncheck "Remember the current page when quitting".

[tigran]

drjenkins,

Thank you! I have unchecked that option and this provided a workaround for this bug. The proper fix for this bug would be to change ebook-viewer to store the position in the proper location in CALIBRE_CONFIG_DIRECTORY or some such like. Certainly NOT in the book file. Imagine that this physical file is under control of some database engine which stores its MD5 checksum and then discovers that the book has changed, thus forcing it to invalidate the entire metadata record and throw it away.

davidfor,

I disagree. It most certainly is a bug and not a feature. A viewer has no right to corrupt my book files with its own private data. This quite clearly constitutes a data corruption and is a very serious bug which should be fixed.

Not a single bit in the book file should be modified by the software called "viewer". If it was called "ebook-editor" or "ebook-writer" then modifying the book file would be a feature and not a bug.

Reading ebook files is orders of magnitude easier than writing them and I cannot imagine that there exists software on this planet capable of correctly rewriting a dozen or so various formats --- this is just too complex of a task. So, I would never trust any software to rewrite my files but I am perfectly happy to trust it to extract metadata and cover image or even attempt to display the content of the first few pages (for the purposes of previewing the book on a computer by a librarian recording its metadata in some database, of course --- not the real reading which should only be done on an eInk device running CoolReader).

[pdurrant]

I tend to agree. Calibre should be storing this metadata somewhere other than the file itself. But I'm not fussed enough myself to see how easy or dificult that would be to implement.

[kovidgoyal]

The viewer stores last read in epub files deliberately, that is a feature and not a bug, and it is not going to change.

Plenty of people, including myself, like having the ability to share bookmarks and last read position to a different machine/person by simply copying the ebook file. If you dont like it, turn it off.

[eschwartz]

Originally Posted by tigran

drjenkins,

Thank you! I have unchecked that option and this provided a workaround for this bug. The proper fix for this bug would be to change ebook-viewer to store the position in the proper location in CALIBRE_CONFIG_DIRECTORY or some such like. Certainly NOT in the book file. Imagine that this physical file is under control of some database engine which stores its MD5 checksum and then discovers that the book has changed, thus forcing it to invalidate the entire metadata record and throw it away.

davidfor,

I disagree. It most certainly is a bug and not a feature. A viewer has no right to corrupt my book files with its own private data. This quite clearly constitutes a data corruption and is a very serious bug which should be fixed.

Not a single bit in the book file should be modified by the software called "viewer". If it was called "ebook-editor" or "ebook-writer" then modifying the book file would be a feature and not a bug.

Reading ebook files is orders of magnitude easier than writing them and I cannot imagine that there exists software on this planet capable of correctly rewriting a dozen or so various formats --- this is just too complex of a task. So, I would never trust any software to rewrite my files but I am perfectly happy to trust it to extract metadata and cover image or even attempt to display the content of the first few pages (for the purposes of previewing the book on a computer by a librarian recording its metadata in some database, of course --- not the real reading which should only be done on an eInk device running CoolReader).

A bug is when something isn't working the way it is meant to. Not when a specific user disagrees about whether it should be done.

You don't believe a program exists to correctly write a dozen formats... but it is all right if a dozen programs exist, each capable of one format? But then they can be combined!
Odd objection... anyway, calibre is that program that doesn't exist.

What database are you using that it cannot handle an edited file and automatically trashes it??? Now THAT is a bug.