Hi Faria,
Please post sequentially, (Bottom post ) and trim all excess stuff, like
signatures. Emulate the style used by Alexander Dalloz and Rick Stevens
and others.
On Thu, May 05, 2005 at 06:21:56AM -0300, Cosme Faria Corrêa wrote:
> Two users can use the same file simultaneously.
> Without a warning.
> OO and gnumeric have this problem.
>
> It is a hell in file sharing.
>
> My test, after a user warning.
> Two user open the same file and no warning.
> They can read and write with freedom.
>
> Do you know how to fix this?
Looks like file sharing is working perfectly. Everybody can read
the file, everybody can write the file. Problem is last person to write
the file loses the changes made by those who wrote out the file just
before him/her.
The best way to allow multiple users to edit the same file without
losing any intervening changes is to use a source code control system.
There are many of these, SCCS, RCS, CVS, Bitkeeper, Subversion and more.
Pick the one you want and place all the files to be shared under that
control system.
If you want the system to do this to individual files, you can try the
following:
You enforce locking at the kernel level with mandatory locks. Mandatory
locking is implemented on a file-by-file basis. When a program attempts
to lock a file with lockf or fcntl that has mandatory locking set, the
kernel will prevent all other programs from accessing the file.[1]
Processes which use flock will not trigger a mandatory lock.
To enable mandatory locking, you must first mount the filesystem with
the mand mount option.
Here is how to change an existing mount to have the mand option:
# mount | grep /data
/dev/hda7 on /data type ext3 (rw,noatime)
# mount -oremount,mand /data
# mount | grep /data
/dev/hda7 on /data type ext3 (rw,mand,noatime)
Add the mand option to the appropriate /etc/fstab entry as well.
To prevent mandatory locking from taking over the entire filesystem,
only specifically tagged files will exhibit mandatory locks. The way you
define a file to be governed by mandatory locks is to set the sgid
(setgroupid) bit, but not the group execute bit. This combination
doesn't make any sense normally,[2] which is why it was chosen for this
purpose.
So, to enforce mandatory locking on the files d_* in a
directory, do the following:
$ cd /data
$ ls -l
-rw-r--r-- 1 userxx stuff 82756 May 28 14:07 a_5772.dat
-rw-r--r-- 1 userxx stuff 7788 May 28 14:07 a_9298.dat
-rw-r--r-- 1 userxx stuff 3325 May 28 14:07 d_0283.dat
-rw-r--r-- 1 userxx stuff 19288 May 28 14:07 d_5755.dat
-rw-r--r-- 1 userxx stuff 1224 May 28 14:07 d_5758.dat
$ chmod g+s,g-x d*
$ ls -l
-rw-r--r-- 1 userxx stuff 82756 May 28 14:07 a_5772.dat
-rw-r--r-- 1 userxx stuff 7788 May 28 14:07 a_9298.dat
-rw-r-Sr-- 1 userxx stuff 3325 May 28 14:07 d_0283.dat
-rw-r-Sr-- 1 userxx stuff 19288 May 28 14:07 d_5755.dat
-rw-r-Sr-- 1 userxx stuff 1224 May 28 14:07 d_5758.dat
Henceforth, the d_* files will exhibit mandatory locking. The capital
"S" in the output signifies that the sgid bit is set, but there is no
underlying execute ("x") bit, which is what we need.
Mandatory locks should only be used where you have problem software you
cannot modify to use locks correctly. Even with mandatory locks, you can
still have conflicts. If program A reads in a file, program B locks,
edits, and unlocks the file, and program A then writes out what it
originally read, you're still in a pickle. However in many cases,
mandatory locking can help prevent corruption of your data.
The other potential problem with mandatory locks is that nothing, not
even root-owned processes, can override the lock. The best root could do
would be to kill the process that has the lock on the file. This could
be particularly nasty if the mandatory-locked file is available via NFS
or other remotely-accessible filesystem, as the entire fileserver
process itself will block until the lock is released.
You will likely find that this technique will cause you more problems
and headaches than using a source code control system.
--
Jeff Kinz, Emergent Research, Hudson, MA.
