Re: File attribute cache bug?

[Michael Albinus]

Kyle VanderBeek <address@hidden> writes:

> I'm using emacs 23.1.1 as packaged for Fedora 11 with the included tramp.  
> I'm seeing a bug that is critical in my work flow between a Linux and FreeBSD 
> machine.
>
> 1. Load remote file that is read only (chmod 0444)
> 2. Change permissions on remote file via a regular shell (chmod 0644)
> 3. Visit file (C-x C-v ENTER) and note that the buffer remains read-only.
>
> What's infuriating about this bug is that it seems to persist despite
> any efforts to re-load the file.  I've killed the buffer and reloaded
> it, and it still comes up as a read-only buffer.  I've loaded it from
> a tramp-dired buffer, same result.  What's more, if I make the buffer
> read-write, emacs changes the mode back to 0444 upon writing (after
> asking if I'm sure I want to try to write it).

You can always apply "M-x revert-buffer", when you have opened the
file in a buffer. This also flushes cached attributes of the related file.

Another alternative is "M-x tramp-cleanup-connection", which flushes
attributes for all files from the cache for a given connection.

> This will impact anyone using Perforce for SCM; it marks files
> read-only until you check them out for editing.  So if I load
> something to look at it before I decide to edit it, I'm stuck with a
> tramp that seems to have cached attributes that are no longer correct.
> It seems to me that tramp should invalidate this cache when I revisit
> the file or examine the directory.

It's a hard trade off between performance and rereading file
attributes. Other people are claiming, that Tramp flushes the file cache
too often ...

These days, I'm playing with time stamps for cached attributes, and
applying an algorithm which checks the validity of cached attributes
based on this. But this is still experimental code, and needs further
improvement.

Sorry for the trouble, and best regards, Michael.