https://bugs.documentfoundation.org/show_bug.cgi?id=100137
--- Comment #31 from [email protected] ---
(In reply to Mike Kaganski from comment #30)
> (In reply to oiaohm from comment #29)
> > 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.
>
> Have you tried that? That's not true.
> The lock file is not the only protection. Actually, the OS will lock the
> original file so that there will be no way to do that massive damage.
> But, of course, another LO trying to open it from original location will not
> know additional info from the lock file, i.e. who exactly opened it. But
> then: lock file isn't part of the standard; and another ODF-authoring
> application (say MS Officce) wouldn't take advantage from the lock file even
> it is there.
This is not understanding the problem.
I have tried it. I did not mention something. Where you must put the lock
file in right place is when you are using NFS or SMB versions/modes that in
fact don't mandate exclusivity or provide server side locking.
OS will always lock the file is a myth. Not all operating systems will lock
the file and not all file systems will let the OS lock the file. The file
systems that will not let OS lock a file will normal be network file system
being using by multi-able users.
https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/locking.html
Yes it a feature of samba that you can in fact disable file locking and there
are registry options in windows to disable OS file locking. There are ways to
turn OS file locking off under OS X and Linux as well. Microsoft windows home
editions come with network file locking disabled.
So absolute yes there is ways to cause massive damage due to the fact the
standard does not define a lock file. A lock file is the only thing that
almost always works. Lock files can suffer from the odd race condition.
Every other form of file locking depends on OS having file locking turn on and
in the case of file servers them in fact keeping track of locking and not
telling every client yes you have that file locked when really its not locking
anything.
So the reality is at the moment every ODF-authoring get to create their own
locking file so users have to choose to use 1 ODF-authoring program or risk
issues if they have a file server that does not respect locking.
>
> As to MS Office that will do a different thing... it will do that *against*
> symlink specifications. And has nothing with ODF. You seem to have no idea
> how standards work. If any standard had to re-do what others do, we would be
> unable to create standards at all.
Standards are to create uniform behaviour. The reality is that every
ODF-authoring program is forced to create lock files. Even MS Office first
version creates lock files for .doc files. So this is universal require
behaviour.
Define symlink handling would also be about creating a uniform behaviour for
ODF programs. Symlinks by standards around symlinks can be used 3 different
ways. ODF standard does not state what one of those 3 ways applications using
ODF files should be using. For lock files resolving symlinks is mandatory.
So if MS Office decides to resolve out a symlink and use that this is not
against symlink standards.
Three different standard usages of symlink
1) treat location of symlink as location of file.
2) Resolve symlink and use location of real file.
3) Do 1 if item cannot be found do 2.
The reality is Libreoffice is using 1 for hyperlinks and 2 for lock files.
This is not a case of redoing this is a case that you need to state what
standard mode of symlink people writing application using ODF should use so
that every ODF-authoring program are handling symlinks in the same way. Yes
adding lock files to ODF standard would mean using resolve symlink and stating
that for lock files that is what is to be used.
Its the Posix standards that define that symlinks can be used the 3 ways.
The problem here is the claim that ODF standard does not need to care about
OS/filesystem-dependent. The reality here when it comes to symlinks the
standard that symlink is from defined 3 options. Libreoffice is using 2 of
the 3 options.
Yes symlink is OS/filesystem-dependent but the standards of symlink define 3
usage modes and ODF does not state what option should be used. Instead you are
presuming just because Libreoffice is using option 1 for hyperlinks that this
is some how correct. The fact Libreoffice is using option 2 for lock files
just shows that symlink usage mode is not OS/filesystem only defined. Instead
symlink usage mode is Application or Standard defined.
Reality using a symlink with ODF since mode of symlink to use is not define in
standard is using undefined behaviour.
This is not re-doing every thing everyone has done. When writing complete
standards some of it is finding the list of items you have to put answers to in
the standard because they are not absolutely defined by everyone else. The 3
usage modes of symlink is one of those things.
Claiming symlink as OS/filesystem-dependant got out of having to in fact answer
the required question of what mode of use for a symlink should be used when
processing an ODF document. In fact standard could define all 3 different
uses of symlink in different places.
Posix and other operating standards only get us so far. After that then it
other standards roles to fill in the gaps. Symlink usage mode selection is
just a gap ODF standard has missed. Lock file is another thing ODF standard
cleanly missed.
--
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
