[Top][All Lists]

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

bug#35418: [PATCH] Don't poll auto-revert files that use notification

From: Michael Albinus
Subject: bug#35418: [PATCH] Don't poll auto-revert files that use notification
Date: Mon, 29 Apr 2019 14:26:09 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Mattias Engdegård <address@hidden> writes:

>> By design, in filenotify.el, we want see only events which are related
>> to the file *name*. If you want to be notified for both buffers, you
>> need to watch both file (names).
> Well yes, but you want a change to the file to be reported for both
> buffers, even if they watch different names, right?

You don't know first hand, which buffers contain the same file hard
linked together. This can be determined only via the inode and device
numbers; something we don't apply yet.

How do you know otherwise, that "/tmp/foo" and "/tmp/bar" are the same,
visited in different buffers?

> Otherwise, it wouldn't make sense at all. If someone is watching a
> file, surely it is because changes to the contents of that file are of
> interest? Why would the name employed to carry out the changes matter?

That's a desirable feature, I agree. But we haven't implemented it
yet. Likely, we shall say so in the doc.

> I'm quite sure there is a simple misunderstanding here; probably my
> fault. And again, I don't think it matters much in practice since
> users are unlikely to have buffers for different hard links to the
> same file. Let's not waste too much time on this.

Agreed. I won't change something in this respect, until there is a bug
report / feature request. And as said, maybe you could add a sentence
about in the manual.

> Thank you. Most of those cases should not cause any trouble -- except
> unreliable file notification processes, but since
> `auto-revert-remote-files' defaults to nil, it didn't look like a
> serious problem.

As Tramp maintainer, I always set `auto-revert-remote-files' to t :-)
So I care.

Best regards, Michael.

reply via email to

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