in reply to IO::Zlib and flock

Do remember that file locking is not supported on some platforms, is not a protection against applications which don't use the same flavor of file locking, and even when all that is okay, it's still just advisory in nature.

To perform a stronger locking scheme, just rename the file to something else during your operation. Of course, if your process crashes and never renames the file, it can be a mess to recover.

--
[ e d @ h a l l e y . c c ]

Replies are listed 'Best First'.
Re: Re: IO::Zlib and flock
by hardburn (Abbot) on May 21, 2003 at 17:32 UTC

    The subroutine above is actually a private method in a class. It's none of my buisness why the application wants the lock, so long as I provide a way to do it.

    That said, I usually do file locking as a CYA measure. Even if it's only advisory locking, I can say "I did my part to keep the file clean. If you didn't do your bit, that's not my problem."

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    Note: All code is untested, unless otherwise stated

Re: Re: IO::Zlib and flock
by perlplexer (Hermit) on May 21, 2003 at 17:44 UTC
    To perform a stronger locking scheme, just rename the file to something else during your operation.

    And exactly how is this stronger? You'll just end up snatching the file from some other application that may be reading/writing from/to it.

    --perlplexer

      File locking doesn't change what another application can or cannot do. Remember the caveats I mentioned. Renaming the file to something else will block another application from subsequently manipulating the file once you've begun your operation.

      Don't think of file locking as "protect myself from the other application's meddling," but rather as "notify other applications of my meddling." If you want to protect your app from others, don't give the other app an opportunity to meddle at all.

      --
      [ e d @ h a l l e y . c c ]