[plug] SOLVED: OpenOffice file locking with Samba

Craig Ringer craig at postnewspapers.com.au
Thu Oct 7 14:27:36 WST 2004


Hi folks

I thought I'd relate a quick solution I ran into to you, to save you all
the pain of dealing with the same problem if you ever have to. As will
become quickly apparent, this has been a source of no small amount of
frustration today, and I never want to see anybody else have to deal
with this if I can avoid it. Consequently, this post has also become
somewhat of a rant. Oh well.

Today, a user reported to me that they'd saved their changes to a file
(in Word, over SMB to our Linux server) and the changes had vanished
when they opened the file again. I initially checked all the usual stuff
- forgot to save, saved somewhere stupid, overwrote it later with a
different version, etc. I was able to fairly confidently rule out each
one. The user is vaguely competent, and what he was saying just didn't
make sense.

I eventually confirmed that they had _not_ been just editing a different
copy, etc. Instead, one of our LTSP users with OO.o had also had the
file open - at the same time.

	local user opens file
	local user saves file
	SMB user opens file
	SMB user saves file
	local user saves file  <--- SMB user's changes nuked here
	local user closes file.

This, of course, should not be possible without at least a warning to
the user. Because the two systems had the same file open r/w at once,
the changes the editor made were just overwritten when the other user
saved their work again. I was astonished that this had happened, and
looked for a fix.

I initially suspected that Samba wasn't setting advisory POSIX locks -
but became clear that it was, and did so automatically. If there were
standard tools to examine such locks it'd be nice, but I guess that'd be
too useful. Perhaps there are and they're just called paflk or something
so you can't guess the name, no matter how hard you look, and there's
nothing like 'lock' in the man summary. There's enough precedent that I
certainly wouldn't be surprised.

Anyway, considerable time and frustration later, I located a post in
Bugarian that gave me the answer.

In brief, it comes down to a what is in my opinion an utterly stupid
default in OpenOffice on Linux - to ignore advisory file locking
completely. Samba sets advisory locks in the kernel when a user is
editing a file over SMB, permitting apps accessing the same filesystem
over NFS or locally to react appropriately to the lock. Other well
behaved apps also do so. Being UNIX, it's optional and mostly ignored,
of course - otherwise it wouldn't hurt enough.

OpenOffice, for example, gleefully overwrites the locked files without
so much as informing the user that there's a lock in place, causing all
sorts of fun with users telling you "my changes just disappeared". For
once, when they blamed the computer, they were right.

To make OpenOffice on Linux behave properly in a multi-user environment,
edit the soffice script and uncomment:

	SAL_ENABLE_FILE_LOCKING=1
	export SAL_ENABLE_FILE_LOCKING

Now, if the file is open by another user anywhere (NFS, SMB, or local)
OO.o will open the file read-only. It still won't do anything silly like
tell the user WHY it's read only, but it won't clobber changes to the
file anymore either. Unfortunately, SMB users using Word seem to get
very unhelpful error messages when files are locked by OO.o, such as
"file or path could not be found". Can't win them all, I guess, and at
least now I won't have any more data loss or the possibility of
important legal changes to stories being lost without detection.

If only UNIX-HATERS was still around...

--
Craig Ringer




More information about the plug mailing list