You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Steve Barham (Created) (JIRA)" <ji...@apache.org> on 2012/04/20 10:22:41 UTC
[jira] [Created] (CAMEL-5196) SftpChangedExclusiveReadLockStrategy
does not check the correct field to determine if a file is changing
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
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
[jira] [Updated] (CAMEL-5196) SftpChangedExclusiveReadLockStrategy
does not check the correct field to determine if a file is changing
Posted by "Steve Barham (Updated) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Resolved] (CAMEL-5196) SftpChangedExclusiveReadLockStrategy
does not check the correct field to determine if a file is changing
Posted by "Claus Ibsen (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-5196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen resolved CAMEL-5196.
--------------------------------
Resolution: Fixed
Fix Version/s: 2.10.0
2.9.3
2.8.5
Assignee: Claus Ibsen
Thanks for the 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
> Assignee: Claus Ibsen
> Labels: locking, patch, regression, sftp
> Fix For: 2.8.5, 2.9.3, 2.10.0
>
> 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