«

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

"kempshall" <> wrote in message
news: oups.com...
> 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.

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 http://www.iviz.com/

On 7 Dec 2005 11:01:42 -0800, "kempshall" <> wrote,
quoted or indirectly quoted someone who said :

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

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