https://bugs.documentfoundation.org/show_bug.cgi?id=100137
--- Comment #29 from oia...@gmail.com ---
(In reply to Mike Kaganski from comment #28)
> 1. There is no other ODF-authoring program that behaves differently. Or am I
> wrong?
At this stage I don't know of one behaving differently. But history of how
Microsoft breaks ODF says if you leave something undefined they will do it
differently to everyone else because they can. Like using MS Office OOXML
formula in ODS instead of openformula because open-formula was not formally
defined. Yes everyone was using openformula in ODS at the time bar Microsoft.
Microsoft windows as only recently got symoblic links we can bet on historic
averages they will do the resolve just to be different unless is forbid. If
it not Microsoft it will be someone else at some point.
Also current symlink handling some editing ODF applications that are not
Libreoffice is broken.
> 2. There is no need to define in ODF standard the things that are
> OS/filesystem-dependent. Symlink is such a feature, and all that any program
> has to know when working with such feature is its name. It needs not to
> bother with its implementation details; the feature is specifically created
> such that all the program has to do is to pass the filepath to OS
> file-handling functions, and get back the contents of the file in return.
> This is the essence of the symlink. It should not be distinguishable from a
> usual file from application PoV. Only low-level utilities need to do other
> things, e.g. archiving software that may need to exclude symlinked stuff
> from archiving because it's actually located in another volume etc.
You want to place a lock file. So that the file you have open editing is not
edited by someone else. Place lock file with the name and location of the
symlink is wrong. The lock file should be placed in the directory with the
real file and every application attempting to open file needs to look in the
same place. Otherwise two or more users could open the file modify and attempt
to save alterations at the same time resulting in massive file damage.
Symlinks are particularly designed to be distinguishable and resolvable for
very practical reasons.
Every time Libreoffice opens a file it detects as a symlink it resolves out the
file back to the original file to place the lock file to place a lock file next
to the original file. For windows 10 now that its displaying symbolic link
files Libreoffice will need an update resolve those or libreoffice will have it
locking broken by symlinks on windows. Also not all ODF editing programs out
there in fact resolve symlinks when locking the file.
So point of view of editing applications they cannot afford to 100 percent
ignore symlinks.
The requirements that an application don't have to care about symlinks.
1) Does not run on any OS that support symlinks.
2) Only access files read only. Never writes so never need to place a lock
file.
OS/filesystem-dependent about symlinks is basically an excuse not to look under
the hood. Basic operations of symlink was defined in posix standards and
every OS implementing have basically all done the same thing with all the same
downsides. Reality is OS X, Linux and Windows symlinks are all
implementations of the same standard with at times to be annoying different ABI
names. I could say that we could ignore the existence of directories because
they are OS/Filesystem-dependent. Yes it basically the same level of
stupidity to say ignore existence of directories when designing as saying
ignore existance of symlinks. href and xlink cover directories and
files(referenced standards in ODF standard to use in those cases).
So any OS posix related with symlinks you have the same rules to work to or
cause hell for yourself or others. One application not resolving symlinks to
place a lock file with ODF could cause a lot of document damage. It would be
good to be able to say that Application is not to ODF standard at least.
Now if ODF applications are locked differently with each ODF editor this is
also going to cause nightmares.
The reality is the path to the real file has to be resolved no matter what
because it required to lock the file for editing/writing or to know if file is
being modified. Do we use that information else where as well that is a good
question. The fact real file-name has to be resolved no matter want to place
required lock file its not very hard to think of an application taking a short
cut and only using the resolved name and completely ignoring the symlink so
being completely different to the current libreoffice behaviour.
If the behaviour is not defined in standard variation in behaviour between
applications using symlinks with odf should be expected to happen.
Individual application-defined behaviour with symlinks is a very fast way to
have hell particularly when they are meant to be handling the same files and
users scratching head why did it work with this program but not that one at
worse why did I magically lose my data.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
