Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > FileWriter.write() does not fail if file is removed after being opened

Reply
Thread Tools

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

 
 
christopher@dailycrossword.com
Guest
Posts: n/a
 
      03-09-2007
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

 
Reply With Quote
 
 
 
 
christopher@dailycrossword.com
Guest
Posts: n/a
 
      03-09-2007
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

On Mar 9, 11:26 am, (E-Mail Removed) wrote:
> 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



 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      03-09-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote On 03/09/07 14:26,:
> 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").

--
(E-Mail Removed)
 
Reply With Quote
 
Chris Uppal
Guest
Posts: n/a
 
      03-09-2007
(E-Mail Removed) wrote:

> 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



 
Reply With Quote
 
Gordon Beaton
Guest
Posts: n/a
 
      03-09-2007
On Fri, 9 Mar 2007 20:49:18 -0000, Chris Uppal wrote:
> (E-Mail Removed) wrote:
>> 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

--
[ don't email me support questions or followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e
 
Reply With Quote
 
John W. Kennedy
Guest
Posts: n/a
 
      03-10-2007
Eric Sosman wrote:
> 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
 
Reply With Quote
 
christopher@dailycrossword.com
Guest
Posts: n/a
 
      03-12-2007
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

On Mar 9, 5:19 pm, "John W. Kennedy" <(E-Mail Removed)> wrote:
> Eric Sosman wrote:
>
> > 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



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to check whether a file is being opened by other programs in Perlscript? Kuhl Perl Misc 6 11-13-2008 06:57 PM
Thumbnail control does not update after images added/removed. RB ASP .Net 2 08-29-2007 01:51 PM
Accidentaly opened I-Bagle - and then opened virus vault ?? Morph Computer Information 2 02-01-2005 03:43 AM
Closing a window by not being the url that opened it Daniele Baroncelli Javascript 1 01-31-2005 03:13 PM
Tomcat JSP session beans not being removed at the end of the session John Smith Java 2 07-15-2004 12:46 PM



Advertisments