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. Thanks, Jordan Grant PS Thanks for the tidbit about renames across devices on other systems! -----Original Message----- From: sebb [mailto:[email protected]] 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 <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
