Error viewing e-books in Calibre

[oldpal]

Frequently after I add an ePub to Calibre and I try to view it I get the following error message. What is the problem? Thanks.

calibre, version 2.72.0
ERROR: Could not open ebook: Failed to read book, /Users/hugh/Calibre Library/William Stevenson/A Man Called Intrepid_ The Incredible True Story of the Master Spy Who Helped Win World War II (616)/A Man Called Intrepid_ The Incredible True - William Stevenson.epub click "Show Details" for more information

Traceback (most recent call last):
File "site-packages/calibre/utils/ipc/simple_worker.py", line 286, in main
File "site-packages/calibre/ebooks/oeb/iterator/book.py", line 64, in extract_book
File "site-packages/calibre/customize/conversion.py", line 245, in __call__
File "site-packages/calibre/ebooks/conversion/plugins/epub_input.py", line 238, in convert
File "site-packages/calibre/utils/localunzip.py", line 231, in extractall
File "site-packages/calibre/utils/localunzip.py", line 213, in _extractall
File "site-packages/calibre/utils/localunzip.py", line 163, in copy_compressed_file
ValueError: Invalid ZIP file, local header is damaged

[Katsunami]

"Invalid ZIP file, local header is damaged"

An EPUB is actually a ZIP-file with a different extension, and Calibre needs to be able to read it as such. This file is damaged, and calibre can't unzip/open it. If you do not have this problem with other books, you'll have to redownload the book again and import it again.

[fidvo]

You could also try this:

1. Save the file somewhere else.

2. Unzip the file. This is the step most likely to fail, but sometimes even if the zip file header is wrong, you might be able to extract it.

3. If you successfully unzipped it, re-zip the file. Change the extension back to .epub

4. Add the book to Calibre temporarily and try to open it in the viewer.

5. If that works, delete the temporary copy and replace the epub format of the original book with the fixed epub.

[PeterT]

I cant help but think the path to the book seems awfully long..

[theducks]

Originally Posted by PeterT

I cant help but think the path to the book seems awfully long..

One of the reasons I split off (manually) subtitles into a custom column,
KISS (Keep It Simply Short )

[gbm]

This ts my path for the same ebook.

/home/xxxxxxx/test library/William Stevenson/A Man Called Intrepid (804)/A Man Called Intrepid - William Stevenson.epub

Opens and works ok.

bernie

[kovidgoyal]

OS X does not have windows' path length limitations

[BetterRed]

Originally Posted by PeterT

I cant help but think the path to the book seems awfully long..

Could be, but after you stick a drive letter and a colon on the front the epub path and wrap it in quotes it is still 'only' 217 bytes long, which is some way short of the 250ish danger zone.

But, I wonder where his %TEMP% folder is, and I wonder how long the xhtml file names are in the book, and are they themselves inside folders. Stripping the subtitle out of the book title in the library manager won't overcome that

@oldpal - if prior suggestions don't help, try assigning the CALIBRE_TEMP_DIR environment variable to a fresh directory with a short pathname - e.g. something like 'c:\_tmp' - see Environment variables

If that works open the the book with the calibre editor with a view to shortening the path lengths within the epub. Or just leave the CALIBRE_TEMP_DIR solution in place.

BR

[PeterT]

@BR It's a Mac....

Sent from my Nexus 7 using Tapatalk

[BetterRed]

Aaah - I interpreted KG's post as a response to bernies post. Calibre errors on OSX sometimes have a "Darwin" tag in them - don't they, maybe not if its in the viewer. or I dreamt it

Aaah-ha - a clue, calibre reports windows paths with sloshes '\', whereas OSX paths have slashes '/', Linux too I guess; must remember that.

BR

[nabsltd]

Originally Posted by BetterRed

Could be, but after you stick a drive letter and a colon on the front the epub path and wrap it in quotes it is still 'only' 217 bytes long, which is some way short of the 250ish danger zone.

Modern (Windows 7 and beyond) Windows path functions support 255 characters per directory and a total path of 65K characters.

Since Calibre hasn't run on Windows XP for over 100 releases, it should be using all modern path functions.

[JSWolf]

Originally Posted by nabsltd

Modern (Windows 7 and beyond) Windows path functions support 255 characters per directory and a total path of 65K characters.

Since Calibre hasn't run on Windows XP for over 100 releases, it should be using all modern path functions.

I have to agree. I would like proper directory support in Windows.

[Katsunami]

The only reason Windows still has a 255 character path limit (per directory, not the entire PATH variable) is to support some very old software. The reason is that in the past, many programming languages such as Pascal used strings as such:

"16this is a string"

The first byte of the string held the length of the string. The above string is 17 characters long, and the first byte denotes the string holds a text of 16 characters.

As a byte only counts from 0 to 255, the text could thus be no longer than 255 characters. To make sure that any programs written in these languages could fit any path returned by DOS within a string, the length of the path was capped at 255.

This limitation has been carried forward for some 35 years now, and I think it's about time it's dropped.

[BetterRed]

Originally Posted by PeterT

@BR It's a Mac....

Moderator Notice

nabsltd, JSWolf, Katsunami - now that it's been established that the OP is using OSX, could you continue this Windows discussion elsewhere

BR

[kovidgoyal]

Originally Posted by nabsltd

Modern (Windows 7 and beyond) Windows path functions support 255 characters per directory and a total path of 65K characters.

Since Calibre hasn't run on Windows XP for over 100 releases, it should be using all modern path functions.

Windows XP also has those modern path functions (though technically speaking, they aren't different functions, just different parameters to the same functions). The problem is not the lack of windows API support for long paths it is that lots of windows software, including windows explorer cannot access paths larger than the old limit.

I dont know why this meme persists on the internet that modern windows has somehow magically learned how to handle long paths. Support for long paths in windows is over a decade old. As of Windows 10 there is now a user controllable registry setting for enabling the old API to also access long paths, but that is totally useless for calibre since something that depnds on a registry setting is not robust.

https://msdn.microsoft.com/en-us/lib...7.aspx#maxpath