Very Computer

I'm not a C programmer so it will be a great help to me if someone
can answer this question. I recently received the following from one
of the programmers where I work:

   unfortunately, linux does not support true file locking, as best I
   can tell. I don't know about the HPUX or the Sun. If you know of a
   way, tell me.

No file locking? Is this possible?
   Currently this programmer is using chmod to prevent other users
and processes from writing to a file, but the chmod fails if the file
is not owned by the user trying to lock it. This encourages users to
all log in as a single user to run this program (uggg!). All in all
it just plain doesn't work right.
   On a machine with the users umask set to 007 and good group
permissions throughout (i.e. directories are 770 and files are 660),
there's just got to be a way for a process owned by "A" to lock a
file owned by "B" while it writes and release it when it's done. Isn't
this exactly the purpose of "flock"? Or if not flock, then something
else more or less as direct?

Bill Cripe

On Thu, 29 Jun 2000 00:21:29 GMT,

Quote:> I'm not a C programmer so it will be a great help to me if someone
> can answer this question. I recently received the following from one
> of the programmers where I work:

>    unfortunately, linux does not support true file locking, as best I
>    can tell. I don't know about the HPUX or the Sun. If you know of a
>    way, tell me.

> No file locking? Is this possible?
>    Currently this programmer is using chmod to prevent other users
> and processes from writing to a file, but the chmod fails if the file
> is not owned by the user trying to lock it. This encourages users to
> all log in as a single user to run this program (uggg!). All in all
> it just plain doesn't work right.
>    On a machine with the users umask set to 007 and good group
> permissions throughout (i.e. directories are 770 and files are 660),
> there's just got to be a way for a process owned by "A" to lock a
> file owned by "B" while it writes and release it when it's done. Isn't
> this exactly the purpose of "flock"? Or if not flock, then something
> else more or less as direct?

Unix doesn't have 'real' file locking.  It has 'advisory' locks of
various sorts, and so-called 'mandatory' locks.  Neither is -really-
mandatory (ie, even with mandatory locks, you can rm a locked file and
write a new file with the same name -- the directory permissions
control the permission to delete or rename a file, not the file or any
locks on it).

Yes, flock will lock a file: it's an advisory lock, though (ie, anyone
else wanting to access the file will need to use flock() to check to see
if they can do it without annoying another process -- they could just
skip that check and write to it anyway).

There is also the so-called 'mandatory' locks, done with the 'lockf' (or
fcntl) function.  These would stop 'most' programs from being *.
But note that others (such as an editor) may do something like the
following as part of their save:
   .  mv file file.bak
   .  write file
   .  (optionally rm the .bak)

Mandatory locks won't stop that, but would probably suffice in most
cases.

See /usr/src/linux/Documentations/mandatory.txt and locks.txt.

--
Brian Moore                       | Of course vi is God's editor.
      Sysadmin, C/Perl Hacker     | If He used Emacs, He'd still be waiting
      Usenet Vandal               |  for it to load on the seventh day.
      Netscum, Bane of Elves.