[CAMEL-5196] SftpChangedExclusiveReadLockStrategy does not check the correct field to determine if a file is changing

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.8.0
• Fix Version/s: 2.8.5, 2.9.3, 2.10.0
• Component/s: camel-ftp
• Labels: locking patch regression sftp
• Patch Info: Patch Available
• Estimated Complexity: Novice
• Regression: Regression
• Assignee: Claus Ibsen
• Reporter: Steve Barham
• Created: 20/Apr/12 08:22
• Updated: 20/Apr/12 09:41
• Resolved: 20/Apr/12 09:41

Description

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.