commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Eckenfels (JIRA)" <>
Subject [jira] [Commented] (IO-544) Could FileUtils.copyFile not be flushed and synced when comparing file sizes?
Date Wed, 05 Jul 2017 20:49:00 GMT


Bernd Eckenfels commented on IO-544:

Do you see the errors between different clients (i.e. Machine1 writes and sends message to
Machine2 which cannot read) or on the same client. Because the later seems to be a Cache bug
the former might be depending on the filesystem. Flush should not help here, if directly followed
by a close(). An sync() might be a optional thing (in that case flush first). However most
network filesystems have a close-to-commit semantic. What FS Server/type is this?

> Could FileUtils.copyFile not be flushed and synced when comparing file sizes?
> -----------------------------------------------------------------------------
>                 Key: IO-544
>                 URL:
>             Project: Commons IO
>          Issue Type: Bug
>          Components: Utilities
>    Affects Versions: 2.5
>         Environment: Win Server 2008, x86
>            Reporter: Sean Poulter
> I've been struggling to troubleshoot intermittent {{IOExceptions}} thrown from {{FileUtils.doCopyFile}}
when copying 2-4KB files from a local temporary file to a network drive. Despite the error,
the file appears on the network drive when I check. Should the output channel/buffer be forced/flushed
before closing, and synchronized before comparing the file lengths? It's a rather intermittent
issue on a relatively high throughput PC so I'd expect there to be more IO latency than normal.
> I found myself referencing:
> * [The source code for FileUtils v2.5|]
> * [FileChannel#force(boolean)|]
> * [IO-443 - FileUtils.copyFile methods throw an unnecessary "Failed to copy full contents
from" exception|]
> Thanks,
> Sean

This message was sent by Atlassian JIRA

View raw message