commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Grant <>
Subject RE: [IO] FileUtils.moveFile/copyFile hangs on OpenVMS when moving largish across physical devices
Date Tue, 22 Oct 2013 14:30:34 GMT
I found that the hanging is due to a known bug in 2.2 (IO-385) that was fixed in 2.5. Unfortunately,
I am on Java 1.5, so I can't upgrade my dependency.  I got the same issue with moveFile and
copyFile because the bug exists in the underlying doCopyFile method that both use.  I do not
allow multiple copies of the output file to exist, as FileUtils will fail if the destination
file already exists, even given the file versioning capabilities of OpenVMS. I expect it would
accept multiple versions of the input file, but I haven't tried.

The strange thing for me is that, in the FileUtils.doCopyFile method in the first iteration
of the loop, a whole buffer (30 MB) worth of data from the FileInputStream channel is transferred
to the FileOutputStream channel. However, in each iteration of the loop afterward, zero bytes
are transferred. Since the loop depends on more than zero bytes being copied each iteration,
the process is stuck in an infinite loop.  

I don't know why my input stream channel transfers zero bytes to the output stream only after
the first iteration.

Jordan Grant

PS Thanks for the tidbit about renames across devices on other systems!

-----Original Message-----
From: sebb [] 
Sent: Thursday, October 17, 2013 6:25 PM
To: Commons Users List
Subject: Re: [IO] FileUtils.moveFile/copyFile hangs on OpenVMS when moving largish across
physical devices

On 18 October 2013 00:07, Jordan Grant <> wrote:
> At my company I've recently run into a bug in Commons-IO 2.2 using the FileUtils.moveFile(File,
File) and FileUtils.copyFile(File, File) method in Java 5.
> The bug causes Java to hang when we attempt to move any >30 MB file across physical
devices on OpenVMS.  The process hangs after OpenVMS has allocated the appropriate file space
and never writes any content to the file.  The process will not error and has to be interrupted
to exit.
> Upon exit, some cache must get flushed, because exactly 31440673 bytes are then written
to the destination file, as long as the source file is larger than that. These methods work
fine on smaller files  (< 30 MB) in the same environment.  I suspect that this is the result
of attempting to first rename the source file to the destination file, which is unsupported
across physical devices on OpenVMS, but the utility falls back on a copy/delete should the
rename fail.  Moving small files in the same manner has never caused us an issue.
> Is there anyone who has run into anything similar or know of any caveats using Apache
Commons in OpenVms for FileUtils?
> In the meantime, we've got a workaround in the format (with better exception handling):
> inStream = FileUtils.openInputStream(srcFile);
>       outStream = FileUtils.openOutputStream(destFile);
>       IOUtils.copy(inStream, outStream);
>       inStream.close()
> outStream.close()
> srcFile.delete()
> One weird thing is that the internal copy method in FileUtils (doCopyFile(final File
srcFile, final File destFile, final boolean preserveFileDate)) does something very similar,
so I would have expected that my workaround would have hung as well.

It seems very odd that your code works but not Commons IO.

Does copyFile fail in the same way as moveFile or is it only moveFile that fails?

Do multiple versions of the source or destination files exist?
Could that be the cause of the problem?
Is there a version limit?

BTW, renames are not allowed across devices on Unix or Windows either; that is a common OS
Allowing multiple versions of files is something that is supported on OpenVMS (but not Unix/Windows)

> Thank you,
> Jordan Grant

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message