Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 317944

Summary:

[ssh] Files accessed via symbolic links are locally cached and don't get updated on remote change

Product:

[Tools] Target Management

Reporter:

Charles Colbourn <charles.colbourn>

Component:

RSE

Assignee:

dsdp.tm.rse-inbox <tm.rse-inbox>

Status:

NEW ---

QA Contact:

Martin Oberhuber <mober.at+eclipse>

Severity:

major

Priority:

CC:

bugs.eclipse.org, charles.colbourn, dmcknigh

Version:

3.1.2

Keywords:

helpwanted

Target Milestone:

---

Hardware:

OS:

All

Whiteboard:

Attachments:

Description	Flags
Changed call to "lstat" with call to "stat" in org.eclipse.rse.internal.services.ssh.files.SftpFileService.getFile	boris.georgiev: review?

Description Charles Colbourn

2010-06-25 06:15:55 EDT

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.

Comment 1 David McKnight

2010-07-07 15:30:53 EDT

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.)?

Comment 2 Charles Colbourn

2010-07-08 03:08:21 EDT

(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.

Comment 3 David McKnight

2010-07-08 09:43:08 EDT

Using dstore, I don't run into this problem but with SSH I do see it.

Comment 4 Martin Oberhuber

2010-07-20 12:22:23 EDT

Increasing priority since this may cause loss of data, and since it's specific to SSH the fix should not be too hard.

Comment 5 Martin Oberhuber

2011-01-12 15:50:35 EST

Community contributions would be appreciated to help fixing this!

Comment 6 Boris Georgiev

2011-09-30 19:39:29 EDT

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.