 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / March 2007FileWriter.write() does not fail if file is removed after being opened
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 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, christop...@dailycrossword.com wrote: > Greetings! > This may be an OS thing, but FileWriter.write(Sting,int,int) thinks it [quoted text clipped - 15 lines] > > clh christopher@dailycrossword.com wrote On 03/09/07 14:26,: > Greetings! > This may be an OS thing, but FileWriter.write(Sting,int,int) thinks it [quoted text clipped - 11 lines] > 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").  SignatureEric.Sosman@sun.com > 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 [quoted text clipped - 3 lines] > 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.) SignatureJohn 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 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 POSIX systems, removing a file merely removes the > [quoted text clipped - 18 lines] > -- Charles Williams. "Taliessin through Logres: Prelude" > * TagZilla 0.066 *http://tagzilla.mozdev.org > 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 >> Well -- it seems that File.canWrite() does check whether the file can >> actually be written each invocation, rather than just whether the [quoted text clipped - 4 lines] > 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 Signature[ 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.