commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [IO] FileUtils.moveFile/copyFile hangs on OpenVMS when moving largish across physical devices
Date Thu, 17 Oct 2013 23:24:52 GMT
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 restriction.
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:

View raw message