FileWriter.write() does not fail if file is removed after being opened

[christopher]

Greetings!
This may be an OS thing, but FileWriter.write(Sting,int,int) thinks it
is writing ok when I remove the file it is writing to after the file
has been opened. No exception is thrown, because the line directly
after the write() and flush() within the try block is executed (I am
catching Exception if that matters). I am speculating that the OS is
not notifying the owner of the file handle (if I an saying it right)
that the file has been deleted / removed / whatever, and that this
might function differently on different systems.

I am trying to create a failover for a log writing thread, and I am
removing the file to simulate an IO error, hehe but that's not
working. Is there a) a better way to simulate an IO error? and b) a
more primitive write method that might throw an exception in this
unlikely circumstance?

Thanx!

clh

 

[christopher]

Well -- it seems that File.canWrite() does check whether the file can
actually be written each invocation, rather than just whether the
owner has the appropriate permissions as I assumed -- it changed state
from true to false after I removed the file, so I just have to add
that logic and all is well. Funny that I would have to check each
time, tho --

Cheers!
-- clh

 

[Eric Sosman]

Greetings!
This may be an OS thing, but FileWriter.write(Sting,int,int) thinks it
is writing ok when I remove the file it is writing to after the file
has been opened. No exception is thrown, because the line directly
after the write() and flush() within the try block is executed (I am
catching Exception if that matters). I am speculating that the OS is
not notifying the owner of the file handle (if I an saying it right)
that the file has been deleted / removed / whatever, and that this
might function differently on different systems.

I am trying to create a failover for a log writing thread, and I am
removing the file to simulate an IO error, hehe but that's not
working. Is there a) a better way to simulate an IO error? and b) a
more primitive write method that might throw an exception in this
unlikely circumstance?

On POSIX systems, removing a file merely removes the
directory entry that points to it. The actual deletion
doesn't occur until the file has been removed *and* all
processes that have the file open have closed it. So
removing your log file while it's being written to does
not actually delete the file (it still exists because it's
still open), but makes it un-findable and subject to
deletion upon being closed.

Windows might be different; I don't do Windows.

If you're on a POSIX system, there are various ways
you can force an error. You could, for example, write to
a named pipe or to a socket, and then kill the program at
the other end. You could (on some systems, anyhow) forcibly
unmount the file system that holds the file.

Some other methods of inducing I/O errors, applicable
to both POSIX and non-POSIX systems, are illustrated here:

http://members.aol.com/spoons1000/break/index.html

(scroll down to "Activity 4").

 

[Chris Uppal]

This may be an OS thing,

Then you should tell us what OS (or OSes) you are targetting.

but FileWriter.write(Sting,int,int) thinks it
is writing ok when I remove the file it is writing to after the file
has been opened.

That's normal behaviour on Unix-like systems. The rules are more complex on
Windows, I think that in general you won't be allowed to remove the file while
it is still open (but there may be exceptions to that "rule").

On Unix it is entirely a routine operation to create a file, open it, remove
that file (actually just remove the file /name/ from the containing directory),
and then continue to use it. It's a good way of creating temporary files which
you /know/ will go away as soon as the process exits.

Well -- it seems that File.canWrite() does check whether the file can
actually be written each invocation, rather than just whether the
owner has the appropriate permissions as I assumed -- it changed state
from true to false after I removed the file[...]

Yes, that's what canWrite() documented to do. If the file doesn't exist then
that method will always return false. Even if you still have that self-same
file open...

-- chris

 

[Gordon Beaton]

Well -- it seems that File.canWrite() does check whether the file can
actually be written each invocation, rather than just whether the
owner has the appropriate permissions as I assumed -- it changed state
from true to false after I removed the file[...]

Yes, that's what canWrite() documented to do. If the file doesn't
exist then that method will always return false. Even if you still
have that self-same file open...

By the same token, I suspect that canWrite() will return true if the
file is removed and (presumably quickly) replaced by a new file with
the same name...

/gordon

 

[John W. Kennedy]

> On POSIX systems, removing a file merely removes the
directory entry that points to it. The actual deletion
doesn't occur until the file has been removed *and* all
processes that have the file open have closed it. So
removing your log file while it's being written to does
not actually delete the file (it still exists because it's
still open), but makes it un-findable and subject to
deletion upon being closed.

Windows might be different; I don't do Windows.

Windows doesn't allow the file to be deleted. (In Windows file systems,
there are no inodes, or, to put it another way, the directory entry /is/
the inode, so it's impossible to have the file half-deleted, as in
POSIX. Therefore, Windows quite sensibly locks out the attempt.)

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"
* TagZilla 0.066 * http://tagzilla.mozdev.org

 

[christopher]

Thanx all -- funny how many assumptions I am using windows. FreeBSD
actually.
I appreciate the info that I am only removing the directory listing --
inode or whatever. Not a good simulation for IO failure at all.

In any event, I am as confident as I can be that the code will handle
any reasonable IO errors now.

Cheers!
-- clh