File locking in Linux - Linux

This is a discussion on File locking in Linux - Linux ; Hello, how can I reproduce the win32 "_sopen" function under Linux/Unix? I'd like to exclusively open a file for read or write or both and set process locks permissions. How can I do it? Thanks in advance, E....

+ Reply to Thread
Results 1 to 17 of 17

Thread: File locking in Linux

  1. File locking in Linux

    Hello, how can I reproduce the win32 "_sopen" function under
    Linux/Unix?
    I'd like to exclusively open a file for read or write or both and set
    process locks permissions.
    How can I do it?

    Thanks in advance,
    E.


  2. Re: File locking in Linux

    Hi.

    oriani.blue_reply@bancaimi.it writes:

    > Hello, how can I reproduce the win32 "_sopen" function under
    > Linux/Unix?
    > I'd like to exclusively open a file for read or write or both and set
    > process locks permissions.
    > How can I do it?


    Use lockf for advisory locking. Do "man lockf" for the details.

    --
    Art Werschulz (agw STRUDEL comcast.net)
    207 Stoughton Ave Cranford NJ 07016
    (908) 272-1146

  3. Re: File locking in Linux



    On Jan 24, 2:32 am, oriani.blue_re...@bancaimi.it wrote:

    > Hello, how can I reproduce the win32 "_sopen" function under
    > Linux/Unix?
    > I'd like to exclusively open a file for read or write or both and set
    > process locks permissions.
    > How can I do it?


    You basically can't. That's the Windows way and it is not the UNIX way.

    DS


  4. Re: File locking in Linux



    On Jan 24, 1:13 pm, "David Schwartz" wrote:
    > On Jan 24, 2:32 am, oriani.blue_re...@bancaimi.it wrote:
    >
    > > Hello, how can I reproduce the win32 "_sopen" function under
    > > Linux/Unix?
    > > I'd like to exclusively open a file for read or write or both and set
    > > process locks permissions.
    > > How can I do it?You basically can't. That's the Windows way and it is not the UNIX way.

    >
    > DS


    Don't tell me that *nix doesn't have a file write/read process
    protection.
    I've tried fcntl with F_SETLK but if you need to protect your file
    while writing it I dunno how to do.

    Cheers!


  5. Re: File locking in Linux



    On Jan 24, 11:32 am, oriani.blue_re...@bancaimi.it wrote:
    > Hello, how can I reproduce the win32 "_sopen" function under
    > Linux/Unix?
    > I'd like to exclusively open a file for read or write or both and set
    > process locks permissions.
    > How can I do it?
    >
    > Thanks in advance,
    > E.


    Damn I read some documentation about advisory and mandatory locking...
    Really there are 2 things I don't like of Linux/Unix
    1) How file permissions are handled (winnt is alot better IMHO)
    2) The lack of support of native mandatory locking!

    Cheers,
    E,


  6. Re: File locking in Linux

    oriani.blue_reply@bancaimi.it wrote:
    >
    > On Jan 24, 11:32 am, oriani.blue_re...@bancaimi.it wrote:
    >
    >>Hello, how can I reproduce the win32 "_sopen" function under
    >>Linux/Unix?
    >>I'd like to exclusively open a file for read or write or both and set
    >>process locks permissions.
    >>How can I do it?
    >>
    >>Thanks in advance,
    >>E.

    >
    >
    > Damn I read some documentation about advisory and mandatory locking...
    > Really there are 2 things I don't like of Linux/Unix
    > 1) How file permissions are handled (winnt is alot better IMHO)


    I smell trolling.

    > 2) The lack of support of native mandatory locking!


    What do you mean by "native mandatory locking"? Something like "_always_
    when one process has a file open for writing, noone can read the file,
    even if the other process is not actually writing the file"?

    There is mandatory locking and advisory locking. Both are in effect only
    when needed. If not used, they don't bother you.

    --
    Josef Möllers (Pinguinpfleger bei FSC)
    If failure had no penalty success would not be a prize
    -- T. Pratchett


  7. Re: File locking in Linux

    oriani.blue_reply@bancaimi.it writes:
    > On Jan 24, 11:32 am, oriani.blue_re...@bancaimi.it wrote:
    >> Hello, how can I reproduce the win32 "_sopen" function under
    >> Linux/Unix?
    >> I'd like to exclusively open a file for read or write or both and set
    >> process locks permissions.
    >> How can I do it?
    >>
    >> Thanks in advance,
    >> E.

    >
    > Damn I read some documentation about advisory and mandatory
    > locking... Really there are 2 things I don't like of Linux/Unix
    >
    > 1) How file permissions are handled (winnt is alot better IMHO)


    If you need ACLs for some reason (but you don't need them most of the
    time, so, the simpler model is a better default), all common Linux
    filesystems support them.

    > 2) The lack of support of native mandatory locking!


    If you want mandatory locking, you need a mount option to tell the
    kernel that you want it and you need to enable it for the files which
    you want to lock this way (see fcntl(2)). But - there be dragons -
    there is a classical pitfall wrt manadatory locking: File locks apply
    to files and not to pathnames. This means that another application can
    unlink the file you have locked and afterwards, create a file with an
    identical name with a different content.

  8. Re: File locking in Linux


    > > 1) How file permissions are handled (winnt is alot better IMHO)If you need ACLs for some reason (but you don't need them most of the

    > time, so, the simpler model is a better default), all common Linux
    > filesystems support them.


    I know pal, just is better to have full control.

    > > 2) The lack of support of native mandatory locking!If you want mandatory locking, you need a mount option to tell the

    > kernel that you want it and you need to enable it for the files which
    > you want to lock this way (see fcntl(2)). But - there be dragons -
    > there is a classical pitfall wrt manadatory locking: File locks apply
    > to files and not to pathnames. This means that another application can
    > unlink the file you have locked and afterwards, create a file with an
    > identical name with a different content.


    Yep I meant this, even with the mandatory mount option you don't have
    the same 'native' feel of mandatory file lock handling as in win32.

    Cheers,
    E.

    Ps. I'm not trolling. I stopped using WinXP since 3 months and use
    Ubuntu 6.10. It's great, I'm really happy, but these 2 'native' (or
    natively -simply) not supported features are just the 2 lacks of
    Linux/Unix. The fact to use the sgid bit to enable mandatory locking is
    the consequence of a bad inheritance. Just this. Happy Linux @ all!


  9. Re: File locking in Linux

    oriani.blue_reply@bancaimi.it writes:
    >> > 1) How file permissions are handled (winnt is alot better IMHO)If you need ACLs for some reason (but you don't need them most of the

    >> time, so, the simpler model is a better default), all common Linux
    >> filesystems support them.

    >
    > I know pal, just is better to have full control.


    That's a meaningless statement in the given context and an assertion
    without backing as well.

    >> > 2) The lack of support of native mandatory locking!If you want mandatory locking, you need a mount option to tell the

    >> kernel that you want it and you need to enable it for the files which
    >> you want to lock this way (see fcntl(2)). But - there be dragons -
    >> there is a classical pitfall wrt manadatory locking: File locks apply
    >> to files and not to pathnames. This means that another application can
    >> unlink the file you have locked and afterwards, create a file with an
    >> identical name with a different content.

    >
    > Yep I meant this,


    Yet you wrote something different.

    [...]

    > Ps. I'm not trolling.


    Anybody willing to accept bets on that?

  10. Re: File locking in Linux

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFFt7roVcFcaSW/uEgRAjo5AKDjZmUIVAD7lqrbs+/qLFQllaMRrgCgi9zw
    UrWmCmIHX7czdx/3RIDnNDY=
    =Cjbq
    -----END PGP SIGNATURE-----

  11. Re: File locking in Linux



    On Jan 24, 6:09 am, oriani.blue_re...@bancaimi.it wrote:

    > 2) The lack of support of native mandatory locking!


    Mandatory locking is broken by design. Locking simply does not work
    unless all the participants cooperate, and if they cooperate,
    cooperative locking is better.

    DS


  12. Re: File locking in Linux



    On Jan 24, 7:26 am, oriani.blue_re...@bancaimi.it wrote:

    > Yep I meant this, even with the mandatory mount option you don't have
    > the same 'native' feel of mandatory file lock handling as in win32.


    Be happy UNIX got it right. Mandatory locking is deadlock prone. One of
    Windows most irritating attributes is the "why can't I delete this
    file, ahh, I have to stop an unstoppable process" problem.

    DS


  13. Re: File locking in Linux



    On Jan 24, 9:00 pm, Roger Leigh
    <${rlei...@invalid.whinlatter.ukfsn.org.invalid> wrote:
    > Use F_WRLCK and F_RDLCK for writers and readers, respectively. The
    > fcntl(2) manual page explains it all. If you want an example, see:
    >
    > Implementation (in C++):
    >
    > http://svn.debian.org/wsvn/buildd-to...build/sbuild-l...
    >
    > file_lock::set_lock is the key part.
    >
    > Examples of read and write locking:
    >
    > http://svn.debian.org/wsvn/buildd-to...build/sbuild-c...
    > (chroot_config::load_data)
    >
    > http://svn.debian.org/wsvn/buildd-to...build/sbuild-c...
    > (sbuild::chroot::setup_session_info)
    >
    > See Stevens' APUE for more detail.
    >
    > Regards,
    > Roger


    Thanks mate, so to use mandatory locking in Linux should I mount any
    partition with this option and then use fcntl?

    >Mandatory locking is broken by design. Locking simply does not work
    >unless all the participants cooperate, and if they cooperate,
    >cooperative locking is better.
    >
    >DS


    I like the idea of collaborative locking is more stadard oriented and,
    can be seen as more community oriented (I share my work with others and
    they should chose to cooperate with my design, not like 'this file is
    mine I don't care about others don't even try to touch it). :-)
    But when you have to be sure no one will modify your file then
    mandatory locking is a must.

    >Be happy UNIX got it right. Mandatory locking is deadlock prone. One of
    >Windows most irritating attributes is the "why can't I delete this
    >file, ahh, I have to stop an unstoppable process" problem.
    >
    >DS


    And yes I agree with you that one has to be careful with these kinds of
    file locks...but to be careful isn't a good reason to implement them in
    a safer way (like one couldn't force the unlink of file as someone
    before pointed out).

    Thanks for clarifications,
    E.


  14. Re: File locking in Linux

    On 2007-01-24, oriani.blue_reply@bancaimi.it wrote:
    >
    >
    > On Jan 24, 1:13 pm, "David Schwartz" wrote:
    >> On Jan 24, 2:32 am, oriani.blue_re...@bancaimi.it wrote:
    >>
    >> > Hello, how can I reproduce the win32 "_sopen" function under
    >> > Linux/Unix?
    >> > I'd like to exclusively open a file for read or write or both and set
    >> > process locks permissions.
    >> > How can I do it?


    >> You basically can't. That's the Windows way and it is not the UNIX way.
    >>
    >> DS

    >
    > Don't tell me that *nix doesn't have a file write/read process
    > protection.
    > I've tried fcntl with F_SETLK but if you need to protect your file
    > while writing it I dunno how to do.


    linux does things differently, In unix the the file is represented by the
    inode, not the directory entry. you can lock the inode and prevent other
    processes from messing with the files contents but that doesn't stop them
    from renaming the file or deleting it and possibly replacing it with another
    file. while this is happening your process will continue to have access to
    the original files content.




    Bye.
    Jasen

  15. Re: File locking in Linux



    On Jan 24, 11:43 pm, oriani.blue_re...@bancaimi.it wrote:

    > But when you have to be sure no one will modify your file then
    > mandatory locking is a must.


    Until someone else makes sure you can't modify your file. Processes in
    a system that all have access to the same file are not at war. They
    must cooperate or the user loses.

    DS


  16. Re: File locking in Linux



    On Jan 26, 12:18 am, "David Schwartz" wrote:
    > On Jan 24, 11:43 pm, oriani.blue_re...@bancaimi.it wrote:
    >
    > > But when you have to be sure no one will modify your file then
    > > mandatory locking is a must.Until someone else makes sure you can't modify your file. Processes in

    > a system that all have access to the same file are not at war. They
    > must cooperate or the user loses.
    >
    > DS


    Hell yeah I agree with your view but the problem is when you have to
    deal with very 'idiot' users not know what they're doing! And I think
    this is a good way to prevent your program crash if someone very
    'smart' would delete or edit the file while your app is
    writing/reading!

    Cheers,
    E.


  17. Re: File locking in Linux

    Hello,

    oriani.blue_reply@bancaimi.it wrote:
    > On Jan 26, 12:18 am, "David Schwartz" wrote:
    >> On Jan 24, 11:43 pm, oriani.blue_re...@bancaimi.it wrote:


    >> > Processes in

    >> a system that all have access to the same file are not at war. They
    >> must cooperate or the user loses.
    >>
    >> DS

    >
    > Hell yeah I agree with your view but the problem is when you have to
    > deal with very 'idiot' users not know what they're doing! And I think
    > this is a good way to prevent your program crash if someone very
    > 'smart' would delete or edit the file while your app is
    > writing/reading!


    But file locking is not quite the right tool for this problem. You would
    better use file access permissions to lock out ordinary users, and let
    your program run under a dedicated user id. E.g. most database servers
    work that way, but more to protect against unauthorized reads, I guess.
    Only those you can trust or must be trusted should have access. Even
    with locks, you would have to make sure, that only trusted parties may
    acquire the lock, or an idiot could lock you out.

    After all, the only thing you can do about uncooperative environments is
    education. It is an important part of working computer systems, which
    is forgotten too often with catastrophic effects: Educating the users.
    You can tell the idiot, what problem it creates what he is doing. In
    the end nothing in a running system is sure, there are ways to destroy
    about everything. An admin must be able to break any lock, for example,
    to handle programs which have gone wild.

    Bernd Strieder


+ Reply to Thread