New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

image lost on resave #247

Closed
ArtiiP opened this Issue Nov 5, 2016 · 4 comments

Comments

Projects
None yet
2 participants
@ArtiiP

ArtiiP commented Nov 5, 2016

i have epub with images:

[root]\1.jpg
[root]\OEBPS\Images\1.jpg
[root]\OEBPS\Images\10.JPG

on save i lost first file from epub
link in document is changed to ../Images/10.jpg

i use sigil .9.7 on windows

@kevinhendricks

This comment has been minimized.

Show comment
Hide comment
@kevinhendricks

kevinhendricks Nov 5, 2016

Contributor

My guess is your manifest entry in the opf for the first image was incorrect on import. If not manifested properly, Sigil will ignore it upon input as it technically is not part of the epub.

Please post the original opf here so that we can check if correct in the first place.
Also what software was used to originally add the image to the epub as it can't have been Sigil.

Kevin

Sent from my iPad

On Nov 5, 2016, at 9:14 AM, ArtiiP notifications@github.com wrote:

i have epub with images:

[root]\1.jpg
[root]\OEBPS\Images\1.jpg
[root]\OEBPS\Images\10.JPG

on save i lost first file from epub
link in document is changed to ../Images/10.jpg

i use sigil .9.7 on windows


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Contributor

kevinhendricks commented Nov 5, 2016

My guess is your manifest entry in the opf for the first image was incorrect on import. If not manifested properly, Sigil will ignore it upon input as it technically is not part of the epub.

Please post the original opf here so that we can check if correct in the first place.
Also what software was used to originally add the image to the epub as it can't have been Sigil.

Kevin

Sent from my iPad

On Nov 5, 2016, at 9:14 AM, ArtiiP notifications@github.com wrote:

i have epub with images:

[root]\1.jpg
[root]\OEBPS\Images\1.jpg
[root]\OEBPS\Images\10.JPG

on save i lost first file from epub
link in document is changed to ../Images/10.jpg

i use sigil .9.7 on windows


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@ArtiiP

This comment has been minimized.

Show comment
Hide comment
@ArtiiP

ArtiiP Nov 5, 2016

well, technicaly it's wrong to ignore image files not listed in manifest :)

but no, all is correct, i can't attach oryginal because i fix it manualy, and don't have broken version.

I trying to create new one, and it's requires some more images (with numbers).

[No data] - Unknown.epub.zip
before use, rename this file to No.data.-.Unknown.epub (don't unpack)

In sigil [root]1.png is wrongly replaced by 9.png on load!

Section0001.xhtml have 3* ico (without "9")

ArtiiP commented Nov 5, 2016

well, technicaly it's wrong to ignore image files not listed in manifest :)

but no, all is correct, i can't attach oryginal because i fix it manualy, and don't have broken version.

I trying to create new one, and it's requires some more images (with numbers).

[No data] - Unknown.epub.zip
before use, rename this file to No.data.-.Unknown.epub (don't unpack)

In sigil [root]1.png is wrongly replaced by 9.png on load!

Section0001.xhtml have 3* ico (without "9")

@kevinhendricks

This comment has been minimized.

Show comment
Hide comment
@kevinhendricks

kevinhendricks Nov 5, 2016

Contributor

Quite the mess actually. Accessing things outside the OEBPS is generally not a good idea.

The improperly placed 1.png gets renamed and added as "9.png" to the Images folder on load into Sigil and "9.png" is different from your own file "9.PNG" so the new name (number based) is technically unique and on Linux with a case sensitive file system all works as intended.

But on Windows which is not case sensitive the "9.png" can not be found by OS levels and a "9.PNG" is loaded instead and saved by the underlying OS. Similar issues exist on Mac OS X if it is set up to use a non-case sensitive file system.

I will modify the unique file name creation to test for existing filenames ignoring case to force a truly unique new name for a file that does not conflict even on an OS with a case insensitive file system.

The easiest workaround is not to use file names that only vary by the case of the extension and to make sure all content is properly inside the OEBPS folder in general (or whatever folder name you typically use).

Thanks for your bug report and your test case. A fix should appear in the next release.

Contributor

kevinhendricks commented Nov 5, 2016

Quite the mess actually. Accessing things outside the OEBPS is generally not a good idea.

The improperly placed 1.png gets renamed and added as "9.png" to the Images folder on load into Sigil and "9.png" is different from your own file "9.PNG" so the new name (number based) is technically unique and on Linux with a case sensitive file system all works as intended.

But on Windows which is not case sensitive the "9.png" can not be found by OS levels and a "9.PNG" is loaded instead and saved by the underlying OS. Similar issues exist on Mac OS X if it is set up to use a non-case sensitive file system.

I will modify the unique file name creation to test for existing filenames ignoring case to force a truly unique new name for a file that does not conflict even on an OS with a case insensitive file system.

The easiest workaround is not to use file names that only vary by the case of the extension and to make sure all content is properly inside the OEBPS folder in general (or whatever folder name you typically use).

Thanks for your bug report and your test case. A fix should appear in the next release.

@kevinhendricks

This comment has been minimized.

Show comment
Hide comment
@kevinhendricks

kevinhendricks Nov 5, 2016

Contributor

Just committed a fix for this to master. Closing this as fixed.

Contributor

kevinhendricks commented Nov 5, 2016

Just committed a fix for this to master. Closing this as fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment