[
https://issues.apache.org/jira/browse/CAMEL-5196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Barham updated CAMEL-5196:
--------------------------------
Attachment:
Switch_to_modified_time_for_remote_timestamp_checks_for_SftpChangedExclusiveReadLockStrate.patch
> SftpChangedExclusiveReadLockStrategy does not check the correct field to
> determine if a file is changing
> --------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-5196
> URL: https://issues.apache.org/jira/browse/CAMEL-5196
> Project: Camel
> Issue Type: Bug
> Components: camel-ftp
> Affects Versions: 2.8.0
> Reporter: Steve Barham
> Labels: locking, patch, regression, sftp
> Attachments:
> Switch_to_modified_time_for_remote_timestamp_checks_for_SftpChangedExclusiveReadLockStrate.patch
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> I have recently upgraded from Camel 2.7 to a more recent version. I can
> confirm that the bug is still in trunk.
> In Camel 2.7, there was a generic FileChangedExclusiveReadLockStrategy. This
> checked the modification time of the file using GenericFile.lastModified.
> This field was set by SftpComponent#asRemoteFile as
> file.getAttrs().getMTime() * 1000.
> In Camel 2.8 onwards, this behaviour is implemented by
> SftpChangedExclusiveReadLockStrategy. This incorrectly (to my mind) retrieves
> the timestamp on line 67 using:
> newLastModified = f.getAttrs().getATime();
> Taking the atime of the file doesn't make a great deal of sense to me; on a
> POSIX compliant filesystem, the atime will be incremented every time the file
> is polled, meaning that this strategy will never be able to mark a file as
> unchanged. While some filesystems are mounted nowadays as noatime or
> relatime, the mtime is still absolutely the safest mechanism to determine if
> something is writing to a target file.
> The impact of this bug is that we cannot reliably poll files from a remote
> SFTP server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
