Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #6320 > unrolled thread

C++ File Lokcing

Back to article view | Back to comp.lang.c++

Contents

  C++ File Lokcing ruben safir <ruben@mrbrklyn.com> - 2011-06-06 22:41 +0000
    Re: C++ File Lokcing "osmium" <r124c4u102@comcast.net> - 2011-06-06 19:25 -0500
      Re: C++ File Lokcing Juha Nieminen <nospam@thanks.invalid> - 2011-06-07 06:25 +0000
      Re: C++ File Lokcing Öö Tiib <ootiib@hot.ee> - 2011-06-07 00:32 -0700
      Re: C++ File Lokcing ruben safir <ruben@mrbrklyn.com> - 2011-06-07 11:54 -0400
        Re: C++ File Lokcing Victor Bazarov <v.bazarov@comcast.invalid> - 2011-06-07 11:55 -0400
          Re: C++ File Lokcing Ruben Safir <ruben@mrbrklyn.com> - 2011-06-07 18:17 +0000
            Re: C++ File Lokcing Victor Bazarov <v.bazarov@comcast.invalid> - 2011-06-07 14:23 -0400
              Re: C++ File Lokcing Ruben Safir <ruben@mrbrklyn.com> - 2011-06-07 18:50 +0000
                Re: C++ File Lokcing Victor Bazarov <v.bazarov@comcast.invalid> - 2011-06-07 15:16 -0400
                Re: C++ File Lokcing Jeff Flinn <TriumphSprint2000@hotmail.com> - 2011-06-07 15:47 -0400
                Re: C++ File Lokcing Paavo Helde <myfirstname@osa.pri.ee> - 2011-06-07 15:04 -0500
                  Re: C++ File Lokcing Ruben Safir <ruben@mrbrklyn.com> - 2011-06-07 22:46 +0000
                    Re: C++ File Lokcing Nobody <nobody@nowhere.com> - 2011-06-08 07:50 +0100
                      Re: C++ File Lokcing Sherm Pendley <sherm.pendley@gmail.com> - 2011-06-08 20:55 -0400
                        Re: C++ File Lokcing Öö Tiib <ootiib@hot.ee> - 2011-06-08 18:33 -0700
                Re: C++ File Lokcing Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-06-08 07:43 +0000
              Re: C++ File Lokcing Nobody <nobody@nowhere.com> - 2011-06-07 21:21 +0100
            Re: C++ File Lokcing Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-06-08 07:21 +0000
            Re: C++ File Lokcing Paavo Helde <myfirstname@osa.pri.ee> - 2011-06-08 16:14 -0500
              Re: C++ File Lokcing drew@furrfu.invalid (Drew Lawson) - 2011-06-08 22:19 +0000
              Re: C++ File Lokcing Nobody <nobody@nowhere.com> - 2011-06-09 02:54 +0100

Page 2 of 2 — ← Prev page 1 [2]

#6450

In article <Xns9EFF26129EB0myfirstnameosapriee@216.196.109.131>
	Paavo Helde <myfirstname@osa.pri.ee> writes:
>
>On a multiuser OS one should not have many files writable by multiple 
>users. This would compromise security as a malicious user could change the 
>data of another user. File locking would not prevent that as the lock is 
>only temporary (and in case of flock(), only advisory). So normally the 
>files a user can write to are used by himself only and non-writable by 
>others, meaning there is no specific problem with a multiuser OS.

The main reason that I've used [whole] file locking is for files
that are shared among related applications that are run by the same
user or group.  Most of that was ages ago, and probably has better
solutions these days.

Locking on part of a file is something I haven't needed, but clearly
has other possible applications.


-- 
 Drew Lawson               And I know there's more to the story
                           I know I need to see more
                           I need to see s'more, hear s'more
                             feel s'more.  I gotta be s'more

[toc] | [prev] | [next] | [standalone]

#6469

On Wed, 08 Jun 2011 16:14:01 -0500, Paavo Helde wrote:

> On a multiuser OS one should not have many files writable by multiple
> users.

That isn't relevant to this thread. Locking is perfectly meaningful even
if a file is mode 0600 (-rw-------), only accessibly by a single user.

> For flock(), the lock is only advisory anyway, so all programs accessing
> the file must actively cooperate. These days much of the stuff is also
> NFS- mounted and flock() does not work there, so I would say it has only a
> very limited niche applicaton. No need to standardize something like that.

Locking is most useful for system processes, where you may have multiple
instances of a single program needing to perform concurrent access on a
shared file. Such files tend to live on the local drive (e.g. /var); NFS
is more common for /home and sometimes for /usr. If you want to put /var
onto NFS, you had better be using a fairly recent NFS version which
provides decent support for locking.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c++

csiph-web