Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / December 2005

Tip: Looking for answers? Try searching our database.

Blocking I/O with FileOutputStream

Thread view: 
kempshall - 07 Dec 2005 19:01 GMT
I'm working on a (trusted) applet that zips a group of files and
uploads them to a server, and also downloads the zipped file and unzips
it. As part of the unzipping process, I call a constructor to
FileOutputStream: FileOutputStream fos = new FileOutputStream( filename
);
The problem is if <filename> is open on the user's machine, this method
throws a FileNotFoundException and stops uncompressing the zip file. Is
there any way to get the FileOutputStream constructor to block until
the user closes the file?

Any help would be greatly appreciated.

--Jay
Matt Humphrey - 07 Dec 2005 19:13 GMT
> I'm working on a (trusted) applet that zips a group of files and
> uploads them to a server, and also downloads the zipped file and unzips
[quoted text clipped - 7 lines]
>
> Any help would be greatly appreciated.

Usually people want to take problematic methods that block and make then not
block so the condition can be handled gracefully rather than the other way
around.  Why not trap the exception as it is and inform the user, asking
them to close the file? Also, the exact meaning of file sharing, locking,
contention-handling, etc, is dependent on the underlying OS. You can easily
make your method block by:

FileOutputStream fos = null;
while (true) {
   try {
       fos = new FileOutputStream (filename);
       break;
  catch (FileNotFoundException ex) {
       // Don't forget to handle the Interrupted Exception
        Thread.sleep (2000);
   }
}
// Use the file

If this is part of a larger mechanism, it may be best to pre-test the
ability to open the file before you begin.

Cheers,
Matt Humphrey   matth@ivizNOSPAM.com  http://www.iviz.com/
Roedy Green - 07 Dec 2005 19:59 GMT
>The problem is if <filename> is open on the user's machine

to a File.canWrite before you start.  If you can't, do a File.exsts.
If it does tell the user to close the file in the other app or chose a
different one, then wait in a modal dialog box until the user says he
has ether fixed the problem or wants to try a different name.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.



Free Magazines

Get 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 ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
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.