Community
Participate
Working Groups
Build Identifier: M20100211-1343 If you have a file on the remote system, and you edit it via a symbolic link, RSE doesn't detect if changes have been made to that file. I assume this is because RSE is checking the time/date on the symbolic link against the time/date in the cache. I don't know if that's by design behaviour, but I would have expected 'right click->refresh' on the file in Remote Systems explorer to update the cache, and it doesn't. This can result in the remote copy of the file being overwritten by a stale copy from cache. Reproducible: Always Steps to Reproduce: 1. Create a file 2. Create a symbolic link to the file 3. Edit via symbolic link using RSE 4. close file in RSE 5. edit via symbolic link remotely using e.g. Vim 6. edit via symbolic link using RSE again File doesn't contain changes made in Vim.
This seems to work okay for me (using the latest 3.2 code). What type of connection are you using (i.e. SSH, FTP, dstore, etc.)?
(In reply to comment #1) > This seems to work okay for me (using the latest 3.2 code). What type of > connection are you using (i.e. SSH, FTP, dstore, etc.)? Version 3.5.2 of Eclipse,RSE 3.1.2,using SSH connections, on this machine. There may be some different installations, quite a few of us use Eclipse. What tends to happen (this bit me big style yesterday) is: someone edits a file via a symbolic link, someone else edits it later, the first person reedits and the seconds persons changes are lost as Eclipse/RSE edits a locally cached version.
Using dstore, I don't run into this problem but with SSH I do see it.
Increasing priority since this may cause loss of data, and since it's specific to SSH the fix should not be too hard.
Community contributions would be appreciated to help fixing this!
Created attachment 204418 [details] Changed call to "lstat" with call to "stat" in org.eclipse.rse.internal.services.ssh.files.SftpFileService.getFile I've investigated the problem and I tracked it down to the usage of "lstat" instead "stat" to get the file attributes. The documentation says "lstat() is identical to stat(), except that if path is a symbolic link, then the link itself is stat-ed, not the file that it refers to. So that is why this happens - instead of returning the modification timestamp of the actual file, the timestamp of the symbolic link is returned. After changing the code to use "stat" instead of "lstat" the problem does not reproduce. I'm not really sure if this behavior is correct for all use cases, but I didn't managed to think of something that will be broken by this change.
