camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (Resolved) (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CAMEL-5196) SftpChangedExclusiveReadLockStrategy does not check the correct field to determine if a file is changing
Date Fri, 20 Apr 2012 09:42:39 GMT

     [ 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

        

Mime
View raw message