How to find out if another process is using a file

[Nick Maclaren]

In article <donn-66A101.12021118012007 at gnus01.u.washington.edu>,
Donn Cave <donn at u.washington.edu> writes:
|> In article <mailman.2878.1169141728.32031.python-list at python.org>,
|>  "Gabriel Genellina" <gagsl-py at yahoo.com.ar> wrote:
|> > "Tom Wright" <tew24 at spam.ac.uk> escribió en el mensaje 
|> > news:eoo6vd$33u$1 at gemini.csx.cam.ac.uk...
|> > 
|> > > I'm writing a program which reads a series of data files as they are 
|> > > dumped
|> > > into a directory by another process.  At the moment, it gets sporadic bugs
|> > > when it tries to read files which are only partially written.
|> > >
|> > > I'm looking for a function which will tell me if a file is opened in
|> > > write-mode by another process - if it is, my program will ignore it for 
|> > > now
|> > > and come back to it later.  This needs to work on linux and windows.  Mac
|> > > OS would be a bonus too.  An os-independent solution would be good, but I
|> > > could write os-specific options and have it pick the appropriate one.
|> > 
|> > Use os.open with the O_EXCL flag; will fail if the other process has the 
|> > file still open (and will fail if another process is reading the file, too, 
|> > not just if someone is writing).
|> 
|> O_EXCL fails if the file exists at all - whether closed or open.

Yes.  In theory.  In practice, it usually works on normal files, provided
that all opens are local.  Under some circumstances, it will even work
for NFS mounted files, as far as I recall.

MVS (now zOS) and other mainframe systems had what the poster wants, but
modern systems don't.  I shall not recommend that the poster asks IBM
for a copy of zOS, for reasons that will be well-known to anyone who used
MVS (which are NOT the ones claimed by the Unix brigade, which are mostly
bogus) :-)

Under Linux, you can do something with fuser, and I am pretty certain that
modern Macintoshes (i.e. BSD) will have an equivalent.  It can't be made
reliable (unlike under MVS), but might reduce the number of problems.


Regards,
Nick Maclaren.