https://bugs.documentfoundation.org/show_bug.cgi?id=100137
--- Comment #27 from [email protected] ---
**The LO behaves correctly with symlinks on all platforms as designed. **
Mike Kaganski you are miss it. Designed as per Libreoffice yes as Designed in
ODF and releated standard the answer is absolute no.
The ODF standard is complete horible here. Yes the standard says you can have
hyperlinks. Then goes and references the xlink and then to href standards that
does not cover what to-do in case of symlink.
So we can at the moment have 2 programs that are exactly to ODF standard. One
resolves the symlink out and the other does not and they are both to current
standard even that to end user they are behaving totally differently. So
Libreoffice is doing here not to ODF or any linked standard so is undefined
action.
Before fixing or closing this bug requires changing what libreoffice is doing
from undefined in standard to defined so that all ODF programs will behave the
same when they hit symlink.
Yes ODF has avoided covering file access and has farmed that out to other
linked standards. Problem is those linked xlink and href standards have a
flaw. Fixing the flaw linked standards will break other standards that define
symlink handling one way or the other. So impossible cat fight. Simplest
solution is just define symlink handling in the ODF standard itself somewhere.
Even if it comes the "ODF application behaviour rules" to guide ODF
implementers to doing what was possible undefined to the same defined path to
follow.
There is another option how symlink could be handled. Of course since the
current standard has it undefined we are free to go where ever.
Resolve on missing. This is where you are using a relative path it attempts
open hyperlink as per normal if file is missing goes look a document see if it
a symlink or not if a symlink resolve and attempt hyperlink with new location
with repeat until either a file is found or is to documents real file with no
more symlinks to resolve.
Resolve on missing would give a nice feature when working with a master
document and you are changing a few sub documents parts to see how it looks.
Symlink master document to a new working directory and place the changed files
in the working directory with resolve on missing it would find the unchanged
documents where the linked lead back to. Resolve on missing would have
hidden the issue you reported.
So there are at least 3 different ways current ODF Standard supporting program
could decide to handle the event of a Symlink file and relative paths. End
users should not have to guess what one and it should not be possible for
conforming programs to put users in location where they have to guess.
Martin Nathansen I know this is not exactly the bug you were thinking of. So
that hyperlinks in ODF documents behaving the same no matter the program
processing the standard need to be updated to clearly state what should happen
with symlinks.
Since this is a case of update start to properly fix we might as well discus
the options.
**File storage isn't what it covers. Don't confuse different things.**
The standard reference for file access by ODF don't cover the Symlink event as
anything other than undefined so do what ever you like.
This is the problem accessing file storage was intentionally put out side the
ODF standard and no one bothered checking if the standards used for file
storage access from ODF in fact covered every possible problem. The answer is
the standards references from ODF for file access all forgot about symlinks.
In fact those standards did not define what should happen in case of symlinks
because it would be too big of a cat fight with the different usage cases.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
