false warnings about remote file changing?

[jeswcollins]

I've been getting warnings about the remote file changing, and asking me to ediff or download. I don't think file has actually changed. It appears the same. Maybe I am saving too many times too quickly in these cases?

Actually, I don't really mind these warnings, but the screen splits (horizontal) sometimes to display them. Can I disable that splitting?

Possibly related issue

[cjohansson]

If you can navigate to any difference regions in ediff then there are actual differences, it could be white-space differences only and that is impossible to spot f you're not using whitespace-mode.

What can happen sometimes is that multiple asynchronous uploads finish in the wrong order, if the connection is slow, maybe your change 2 got uploaded before change 1 and this will make the plug-in think that change 2 is the latest revision even though change 1 was before it. So it's kind of a race condition issue. When change 1 is being uploaded it will compare remote contents with local-revision and this could have been updated when change 2 was uploaded..

In these cases, just uploading with force will solve the problem. If you press the ssh-deploy difference action and ediff is opened it means the files are actually different, otherwise you will just get a message in the mini-buffer that the files have identical contents.

Technically I don't think it's a bug but it is an issue that can happen in some cases with asynchronous uploads on a slow connection

[cjohansson]

Please let me know if you can reproduce the issue, I get it sometimes and I believe it's related to a race-condition happening with multiple asynchronous uploads of the same file. The latest revision is the latest uploaded contents so I think in some cases this gets out of sync. I am not sure how to solve that problem, maybe I could add a lock mechanism preventing more than one asynchronous operation on the same file at a time?

[jeswcollins]

Will let you know if I reproduce this issue and what an ediff results in, but I think files are the same by the time I compared them. Yes, I think your explanation of a race-condition on multiple asynchronous uploads of the same file makes sense. If I remember correctly, I observed the issue only when saving multiple times in short time span (guessing order of 2-3 saves within as many seconds).

I don't know enough about the ssh protocol, but I'm wondering whether timestamps could be compared instead of a file lock?

[cjohansson]

Thanks for the update, I get this issue sometimes myself when saving multiple times when on a bad connection

[d-r-jenkins]

I have the same issue and have not yet been able to upload any files with this.

When I do a diff between the remote and local versions there is no difference, but when I run a rsync -azP command then the file I attempted to upload is downloaded again, having been marked as being edited, but the timestamp has not changed.

If it makes a difference I am using doom emacs.

the contents of my .dir-locals.el is

((nil . (
  (ssh-deploy-root-local . "/path/to/dir")
  (ssh-deploy-root-remote . "/ssh:me@host:/path/to/remote/dir")
  (ssh-deploy-on-explicit-save . 1)
)))

and I have nothing regarding ssh-deploy in my configuration files.

I am fairly new to emacs and only found this package today, so I may just be doing something very stupid!

[cjohansson]

It uploads only files and not buffers, so if you upload an unsaved buffer (related to a file) it will actually upload the file as in the last saved state.

The diff will also detect white-space differences so there can be non-visible differences in the files.

If you download the file first, before doing any edits, the issue should disappear. You can also force upload the file and it will discard differences.

There is also a global setting available to discard differences altogether.