Possible to test if file is open?

[Chris]

I need to test if a file is open by another process.

The "other process" will always be another instance of my program,
possibly running on a physically separate server, and accessing the file
on a shared drive.

Is this possible in Java?

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I need to test if a file is open by another process.

The "other process" will always be another instance of my program,
possibly running on a physically separate server, and accessing the file
on a shared drive.

Is this possible in Java?

You can try FileChannel lock.

But whether it will work as you want depends
on the operating system and the software providing
the shared drive.

Arne

 

[Daniel Pitts]

I need to test if a file is open by another process.

The "other process" will always be another instance of my program,
possibly running on a physically separate server, and accessing the file
on a shared drive.

Is this possible in Java?

Open it with exclusive access? I'm not sure if its possible in Java,
but I'd be surprised if it wasn't.

 

[Mike Schilling]

On Windows, you can try to delete it, sicne Windows won't let you delete an
open file.

This approach does have certain disadvantages.

 

[ck]

On Windows, you can try to delete it, sicne Windows won't let you delete an
open file.

This approach does have certain disadvantages.

Not necessary. Try this out on windows. Open any text document in
notepad, and then try to delete. Document gets deleted.

Cheers,
Ck
http://www.gfour.net

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Not necessary. Try this out on windows. Open any text document in
notepad, and then try to delete. Document gets deleted.

And what does that prove ?

Most likely that notepad does not keep the file
open (in the meaning of "open file" used by programmers).

Arne

 

[ck]

And what does that prove ?

Most likely that notepad does not keep the file
open (in the meaning of "open file" used by programmers).

Arne

Well I did not try to prove anything. The question was can we do check
if the file is open by another process or not, so there could be a lot
of other process (like notepad) which might use the file without
locking out the file.

Cheers,
Ck
http://www.gfour.net

 

[mearvk]

Check out this URL:
http://java.sun.com/j2se/1.5.0/docs/api/java/nio/channels/FileChannel.html

FileChannel.tryLock()
FileChannel.lock()

These won't tell you if another process has the file open
non-exclusively, but they will tell you if they are open by a process
exclusively.

Mearvk

 

[Lew]

Well I did not try to prove anything. The question was can we do check
if the file is open by another process or not, so there could be a lot
of other process (like notepad) which might use the file without
locking out the file.

The question, as you pointed out, is whether the file is *open* by another
process or notl your example did not actually address that issue. If notepad
is not holding the file open, as Arne explained, then it is not part of the
scenario in question.


You did realize that this was not actually a serious suggestion, right?

- Lew

 

[Martin Gregorie]

Experience says that most ASCII text editors (notepad, vi, microEmacs.
PFE etc) do not hold files open. Each load and save operation typically
opens the file, does what it needs to do and closes it again.

Many word processors, OTOH, seem to hold files open. I think Word falls
into this class but can't prove it.

But, why just speculate about this when you can easily try an
experiment. All you need is a simple CLI program whose logic is
something line:

open a file
write a prompt to the console
read the response to the prompt
close the file
exit

The program could have options to write or read the file. Its benefit is
that, unlike using some program with unknown characteristics, with this
you *KNOW* that the file is open once you've seen the prompt but haven't
yet responded to it. At this point you can run other commands or even
(shock, horror!) code that you think should check whether the file is in
use or not.

Running tests is the only safe way to go because actual behavior is
likely to be platform-specific. I'd guess that File.canRead() and
File.canWrite() may detect file locks under most Unices, MVS or
Guardian, because these OSen have kernel support for file locking, but
probably do not under Windows. I may be wrong here because I haven't
seriously programmed for that environment since Win 95: IIRC there is no
kernel level locking in Win 95 or its associated version of DOS.

 

[ck]

Experience says that most ASCII text editors (notepad, vi, microEmacs.
PFE etc) do not hold files open. Each load and save operation typically
opens the file, does what it needs to do and closes it again.

I am not sure about vi either. It gives a warning if you try to open an
already open file.

# E325: ATTENTION
# Found a swap file by the name ".s6.c.swp"
# Swap file ".s6.c.swp" already exists!

I guess its not due to lock but due to existence of a swap file.

Cheers,
Ck

 

[Martin Gregorie]

# E325: ATTENTION
# Found a swap file by the name ".s6.c.swp"
# Swap file ".s6.c.swp" already exists!

I guess its not due to lock but due to existence of a swap file.

Yes. A quick glance at the manpage says that vi uses it primarily for
recovery after a crash. There will always be a swap file (unless the
user invoked the option to disable it) BUT it isn't the same as the file
being edited. Its name is the same as the file being edited with ".swp"
appended. At least, that applies to vim but may not apply to other
implementations like stevie and elvis. he lightweight vi clone pvic
doesn't use a swap file.