bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#54126: 29.0.50; C-x x g doesn't always correctly revert SSHFS files


From: Philipp Stephani
Subject: bug#54126: 29.0.50; C-x x g doesn't always correctly revert SSHFS files
Date: Fri, 18 Mar 2022 17:21:54 +0100

Am Mi., 23. Feb. 2022 um 16:14 Uhr schrieb Michael Albinus
<michael.albinus@gmx.de>:
>
> Philipp Stephani <p.stephani2@gmail.com> writes:
>
> Hi Philipp,
>
> > At least on my system the following happens often, but not always:
> >
> > Create some file whose contents don't really matter.  In my case:
> >
> > $ cat /tmp/a.c
> > int main(void) {
> >   return 0;
> > }
> >
> > Visit the file over SSHFS:
> >
> > $ emacs -Q /sshfs:localhost:/tmp/a.c
> >
> > Now, outside of Emacs, append something to the file:
> >
> > $ echo aaaaa >> /tmp/a.c
> >
> > Immediately after that, back in Emacs, hit C-x x g.  The new content
> > isn't there.  Only after reverting the buffer a second time it appears.
> > First I thought this was a timing/cache coherency issue, but even
> > waiting for 10 seconds doesn't fix it in most cases.  Somewhat
> > surprisingly, switching to a different buffer in between appears to make
> > the problem go away (in some cases at least).
>
> Looks like you are plagued by caching. revert-buffer reverts a file
> only, if it is modified on disk. Tramps caches file attributes by
> default for 10 seconds (see remote-file-name-inhibit-cache). Set this
> value to t in order to test, whether it makes a difference. However, you
> have said you did wait for 10 seconds, so maybe this isn't the reason.

I didn't use a stopwatch :-)
So if the cache timeout is really exactly 10 seconds, then it's rather
likely I was affected by it.
This doesn't seem to happen with SSH, only with SSHFS, though. Does
the caching behavior differ? I.e., is the SSH backend stricter about
cache coherency?
It's also worth noting that Unix tools generally expect filesystems to
be sequentially consistent (i.e. any modification is immediately
visible by any other consumer, and there's a strict ordering between
operations). Caching is still possible, but it shouldn't break these
consistency guarantees.

>
> Another cache might come from sshfs itself. Tramp calls sshfs like
> "sshfs localhost:/ /tmp/tramp.sshfs.localhost -C -o idmap=user,reconnect".
> See tramp-mount-args settings in tramp-sshfs.el, line 33-34. You might
> try to add other options, like "-o no_readahead" or "-o sync_readdir",
> see sshfs(1). Don't forget to unmount the sshfs mount point, before you
> start a new Emacs session with changed options.

I'll play around with that, thanks for the hint.
If this turns out to be the problem, then caching should probably be
disabled by default, because sequential consistency is more important
than potential speed-ups.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]