Mobileread
New message when I open Sigil 0.9.17
#11  KevinH 08-18-2019, 04:15 PM
This is so strange...

It walked the manifest file and built up the file paths from the temporary Directory that Sigil created to store the unzipped epub:

Here is the temporary directory used to unpack the epub into:

m_ExtractedFolderPath: "/var/folders/kl/5s_sbwr972n1qq9xrk7rlyvr0000gn/T/Sigil-DTjJwa"


Here is the complete file path used to store one of the files as an example:

Debug: creating manifest file path from: "/var/folders/kl/5s_sbwr972n1qq9xrk7rlyvr0000gn/T/Sigil-DTjJwa/OEBPS/Text/ded01.xhtml"


But when you ask for the epub root relative file path for that file it comes back with
something that makes no sense:

Debug: Manifest File Paths:
Debug: "-DTjJwa/OEBPS/Text/ded01.xhtml

instead of the expected:

OEBPS/Text/ded01.xhtml

It is almost as if the temp folder name has embedded null characters of some sort!

Not sure why this is happening, but there is nothing wrong with the epub itself. The problem is in how mac OSX 10.14 is generating temp folder paths. It seems to be embedding nulls or other invisible characters so that a count of the strings can not be used to remove the root folder from the name.

This is very strange.

I will have to dig deeper.

KevinH
Reply 

#12  KevinH 08-18-2019, 04:30 PM
Okay this is because macOS is using symlinks in creating the tempfolder path that are not resolved:

dynabook/

Please do the following in Terminal.app
cd /
ls -al /var
ls -al /tmp

and report back what they say:

On my machine:

ls -al /var reports:
/var -> private/var

and ls -al /tmp reports:

/tmp -> private/tmp
Reply 

#13  DiapDealer 08-18-2019, 04:39 PM
In this commit: https://github.com/Sigil-Ebook/Sigil/commit/7caadee9ee7f8ccc7c427ce8eb517017fbc659d5

Is m_ExtractedFolderPath canonical? And if not, shouldn't it be? If it's absolute, then you might be subtracting apples from oranges to get the relative path. Canonical should remove symbolic links.
Reply 

#14  KevinH 08-18-2019, 04:39 PM
I think the problem is the call to create a canonical path for each manifest file. On my machine it will not resolve the symlinks, and on your machine it resolves the symlinks so it converts:

converts:

"/var/folders/kl/5s_sbwr972n1qq9xrk7rlyvr0000gn/T/Sigil-DTjJwa/OEBPS/Text/ded01.xhtml"

to

/private/var/folders/kl/5s_sbwr972n1qq9xrk7rlyvr0000gn/T/Sigil-DTjJwa/OEBPS/Text/ded01.xhtml

And when I remove the length of the m_ExtractedFolderPath which was:

"/var/folders/kl/5s_sbwr972n1qq9xrk7rlyvr0000gn/T/Sigil-DTjJwa"

I end up with leaving 8 characters too many in the path (length of "/private").

So this appears to be caused by a change in how canonicalFilePaths are being resolved in macOS 10.13 and earlier and macOS10.14 and later.

This would cause lots of havoc in just about everything to do with launching a new file with open with as well.

"canonicalFilePaths" are supposed to have all symlinks resolved but that does not happen on my machine but does seem to happen on your machine.

So I think this is a bug fix made by Apple for macOS 10.14 that breaks Sigil.

I will look into fixing this.
Reply 

#15  KevinH 08-18-2019, 04:47 PM
Yes but using a canonical file for the temp folder created another issue for macOS a ways back (and if our call to canonical is broken - that explains why.

So the best solution is not to resolve relative hrefs from the manifest using canonical but instead to do it the way I have just added to PageEdit (a utility routine) that will work for all platforms.

What we need is an absolute path without relative segments if canonical is broken on macOS and sometimes doesn't resolve all symlinks that start at root.

I guess we could start with a canonical name in TempFolder and if that breaks me (my macos 10.13 machine) we can try to just resolve relative links and not symlinks and let the symlinks live. The problem is hard links will then break the canonical file paths as will some aliases. Hmm....

Kevin




Quote DiapDealer
In this commit: https://github.com/Sigil-Ebook/Sigil/commit/7caadee9ee7f8ccc7c427ce8eb517017fbc659d5

Is m_ExtractedFolderPath canonical? And if not, shouldn't it be? If it's absolute, then you might be subtracting apples from oranges to get the relative path. Canonical should remove symbolic links.
Reply 

#16  DiapDealer 08-18-2019, 04:57 PM
Gotcha. Can it be worked around in the meantime by manually setting a Sigil temp path (one that doesn't contain any symlinks)?
Reply 

#17  KevinH 08-18-2019, 05:09 PM
Yes that should work!

Brilliant!

Quote DiapDealer
Gotcha. Can it be worked around in the meantime by manually setting a Sigil temp path (one that doesn't contain any symlinks)?
Reply 

#18  KevinH 08-18-2019, 05:10 PM
I am going to push a change to use the same approach to resolve relative segments in absolute paths and see if that will work for all platforms (even our broken one!)

KevinH
Reply 

#19  KevinH 08-18-2019, 05:21 PM
To make matters worse, I am not sure how the Qt FileWatcher handle symlinks if we register it one way and the change comes from an alternative path.

We really want to use absolute paths without relative segments everyplace and be consistent to work around the inconsistent versions on macOS.

So I have taken a shot at pushing that with the only use of canonical is to the application to be launched in OpenExternally but that is used on Windows only so should be fine!

Just pushed the change.
Reply 

#20  DiapDealer 08-18-2019, 05:33 PM
The one in Windows (which is brand new, by the way) may not even be necessary. I just wasn't entirely certain how cmd might handle quoted paths containing relative segments (if that situation could even arise). It was a CYA inclusion on my part. Could be overkill.
Reply 

 « First  « Prev Next »  Last »  (2/3)
Today's Posts | Search this Thread | Login | Register