ADE refusing epub

[PalingB]

Originally Posted by Doitsu

There was a bug in my ePubCheck plugin that might have caused ePubs to be saved with two mimetype files if the epub was saved after running the ePubCheck plugin. I've uploaded a fixed version in the epubcheck plugin thread.
I'd strongly recommend re-saving all ePubs that you edited and saved immediately after running the ePubCheck plugin.
(Re-opening and re-saving ePubs with two mimetype files with Sigil 0.9.2 or Calibre Editor will automatically delete the extra mimetype.)

I'm really sorry for any inconvenience that this bug has caused you.

Update UpubCheck 3.5 works fine, thanks

[exaltedwombat]

Originally Posted by Doitsu

There was a bug in my ePubCheck plugin that might have caused ePubs to be saved with two mimetype files if the epub was saved after running the ePubCheck plugin. I've uploaded a fixed version in the epubcheck plugin thread.
I'd strongly recommend re-saving all ePubs that you edited and saved immediately after running the ePubCheck plugin.
(Re-opening and re-saving ePubs with two mimetype files with Sigil 0.9.2 or Calibre Editor will automatically delete the extra mimetype.)

I'm really sorry for any inconvenience that this bug has caused you.

That sounds a very plausible solution! Thank you very much. That particular job was sent off and approved (on Christmas Day - there are some seriously sad people in this business). But I look forward to experimenting and confirming, and then moving on to your updated plugin.

[exaltedwombat]

Yes, confirmed. I guess it's because running a check before saving is such a reflex action...

But surely a checking utility should read and report on the code, not change it?
https://photos.google.com/photo/AF1Q...I5f8eqK6vEyrSC

[DiapDealer]

Originally Posted by exaltedwombat

But surely a checking utility should read and report on the code, not change it?

Well, yes. That's why it was a bug.

[exaltedwombat]

I'm not knocking you, and thanks for your invaluable work. But I'm trying to get my head round the concept that a validation utility has any business being able to do anything except look at a file, display a report and maybe write a log file.

[Divingduck]

Originally Posted by JSWolf

Then I suggest also installing ADE 2.0.1 as you'll need to make sure your ePub works with that version as a lot of older devices use an older version RMDSK. I don't know if you can install 2.0.1 on the same computer as 4.5. I was able to install 2.0 alongside 1.7.2.

Yes you can. I have all major versions running parallel (1.7, 2.01, 3.0, 4.5) on my OS. You can't install updates like 2.0 parallel to 2.01 etc.

By the way, I never had trouble with using 4.5. I am testing all my epubs with ADE as last checkup. If there are problems they happen (from my own experience until now) with all versions.

@PalingB, thanks for your tip. Good to know.

[Doitsu]

Originally Posted by exaltedwombat

But I'm trying to get my head round the concept that a validation utility has any business being able to do anything except look at a file, display a report and maybe write a log file.

The problem was that I took a shortcut; I processed the files in the scratchpad temp folder created by Sigil instead of copying them to a separate temp folder.
However, since epubcheck requires a mimetype file (which Sigil never wrote to the temp folder), I wrote a mimetype file in the temp folder (nothing else was touched), because I erroneously assumed that Sigil would do the same before saving the file thus overwriting my file. I had also checked all files after running the plugin and saving them with a standalone epubcheck version, which didn't report any errors. It had also never occurred to me that Sigil would add another mimetype upon saving the .epub file. I actually thought it was impossible that a .zip could contain the same file twice.
As I've already mentioned, the epubcheck plugin only caused the double mimetype problem if you ran the plugin, corrected reported errors and immediately saved it afterwards.
If you ran the epubcheck plugin and closed the file after it reported no errors there shouldn't be any mimetype problems.
Like I've said, I'm really sorry that my shortcut caused you all these problems, had it not been for your bug report and DiapDealer's superior sleuthing skills I would have never noticed it.

@DiapDealer & KevinH: I'm curious: is having two files with the exact same file name and content in the same location of a .zip file a standard .zip file feature or did Sigil save the .ePub file in a special non-standard .zip file format?

[DiapDealer]

Originally Posted by exaltedwombat

I'm not knocking you, and thanks for your invaluable work. But I'm trying to get my head round the concept that a validation utility has any business being able to do anything except look at a file, display a report and maybe write a log file.

It's because the unzipped temp directory that Sigil works out of (the scratch directory) does not include a mimetype file. And epubcheck expects one, so one needs to be created before submitting the structure to the validator. The way to achieve this (that the plugin now does) is to copy the books contents to a temp directory, create the mimetype file there, and then submit it all to the validator. The EpubCheck validation process, itself, makes no changes to any files whatsovever (as one would expect). It's the plugin that needs to create something so that EpubCheck has everything it expects to be present.

EDIT: as Doitsu already explained while I was fat-fingering.

[DiapDealer]

Originally Posted by Doitsu

@DiapDealer & KevinH: I'm curious: is having two files with the exact same file name and content in the same location of a .zip file a standard .zip file feature or did Sigil save the .ePub file in a special non-standard .zip file format?

Not sure. In my mind, two files with the same name should be impossible (in the same zip archive). I don't think the file truly exists in the archive since only one exists after unzipping it, so I think it's probably something to do with the zip file's namelist property. That would explain why epubcheck doesn't bark about it. Because once it unzips the archive, the issue no longer exists. Bit of a catch-22 thing going on.

[Doitsu]

Originally Posted by DiapDealer

I don't think the file truly exists in the archive since only one exists after unzipping it, so I think it's probably something to do with the zip file's namelist property. That would explain why epubcheck doesn't bark about it. Because once it unzips the archive, the issue no longer exists. Bit of a catch-22 thing going on.

Thanks for the explanation. So I guess what I accidentally created (with the help of Sigil) was kind of a case of Schrödinger's cat.

[exaltedwombat]

A thoroughly satisfying conclusion for all concerned, I think. Well done, and thanks!

[Hitch]

Originally Posted by exaltedwombat

That sounds a very plausible solution! Thank you very much. That particular job was sent off and approved (on Christmas Day - there are some seriously sad people in this business). But I look forward to experimenting and confirming, and then moving on to your updated plugin.

ExW:

Yeah. We sent one off at 2:00 a.m., Xmas morning, and another at 3:00 p.m. Xmas day. These are in addition to a bunch shipped middle-of-the-night, etc., in the 4 days leading up to same. (I had more than one person working 20-hour shifts, pushing into the holiday.)

Altho we make a massive effort each year to have EVERY book in the shop out the door by noon on the 24th, this year, we had a lot of really difficult books, some that were crazy-hard. I admit to a bit of gobsmackery that so many clients INSISTED that we had to push the books out, Christmas or no Christmas. This racket gets harder to live with every day, doesn't it?

I feel for ya. And I completely understand the issue with ADE 4.x, believe me.

I now return this thread to its topic. :-)

Hitch