[Top][All Lists]

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

Re: file-exists-p can return t when file doesn't exist

From: Michael Albinus
Subject: Re: file-exists-p can return t when file doesn't exist
Date: Mon, 02 Aug 2010 10:28:22 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Leo <address@hidden> writes:

> Hello,


> I find that file-exists-p can return t on a non-existing file and
> because of this causing errors in subsequent operations. My current
> workaround is to reset tramp-cache-data.
> It is clear a bug on tramp's part. I am using the version of tramp on
> the emacs-23 branch of emacs upstream. Any idea for a fix?
> Sorry I haven't found a recipe to reproduce it yet but basically it
> happens often enough when using magit on a remote git repo. The cause
> seems to be tramp caches the info whether a file exists on remote
> machine but in the process of git operations some file disappears and
> tramp continues to use the cache. The culprit is this snippet (NB it
> doesn't involve magit)

I've checked magit.el from AFAICS it
shouldn't run on a remote host, because it uses `call-process' and
`start-process'. Did you patch magit.el, or do you use a version from
somewhere else?

Anyway, there is a problem with Tramp's caches, indeed. For synchronous
processes, there exists the variable `process-file-side-effects', which
tells Tramp whether to flush the cache after a call of
`process-file'. Since its default value is t, this happens for all
synchronous processes if not said otherwise.

But magit calls also asynchronous processes. In this case, we have no
indicator when to flush Tramp's cache, because we don't know when this
process is done. Therefore, such cache inconsistencies could happen. In
magit.el this is the case for the `magit-run-async' calls, ie

  (magit-run-async "git" "remote" "update")
  (magit-run-async "git" "pull" "-v")
  (magit-run-async "git" "push" "-v" push-remote branch)

I have no good idea how to solve it. One could set a process sentinel,
but this will be overwritten, if the process owner sets an own sentinel,
like it is done in `magit-run*'.

> Best wishes,
> Leo

Best regards, Michael.

reply via email to

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