autoreverting remote files

autoreverting remote files

[Michael Albinus]

Hi,

in autorevert.el, remote files are excluded from operation. There are
good reasons for this; mainly due to slow access.

However, there are use cases where it might be acceptable to handle
remote files, too. For example, watching a log file via
`auto-revert-tail-mode', which can be accessed as root only.

Therefore, I propose a new option `auto-revert-remote-interval'. This
shall have the same meaning as `auto-revert-interval' for local
files. The default value is nil, which means that remote files are not
reverted. And the users shall be guided, that a good value shall be
bigger than the default 5 seconds of `auto-revert-interval'.

Additionally, one would need the new defun `auto-revert-set-remote-timer'.

Opinions?

Best regards, Michael.

Re: autoreverting remote files

[Deniz Dogan]

The first thing that I come to think of is what should happen should
the request take longer than the interval. I'd like a feature which
increases the interval automagically depending on how long requests
take. It would also decrease the interval (but at no point go below
the user set value) if the request takes less time than the current
interval.

--
Deniz Dogan

2009/7/25, Michael Albinus <michael.albinus@gmx.de>:
> Hi,
>
> in autorevert.el, remote files are excluded from operation. There are
> good reasons for this; mainly due to slow access.
>
> However, there are use cases where it might be acceptable to handle
> remote files, too. For example, watching a log file via
> `auto-revert-tail-mode', which can be accessed as root only.
>
> Therefore, I propose a new option `auto-revert-remote-interval'. This
> shall have the same meaning as `auto-revert-interval' for local
> files. The default value is nil, which means that remote files are not
> reverted. And the users shall be guided, that a good value shall be
> bigger than the default 5 seconds of `auto-revert-interval'.
>
> Additionally, one would need the new defun `auto-revert-set-remote-timer'.
>
> Opinions?
>
> Best regards, Michael.
>
>
>


-- 
Deniz Dogan

Re: autoreverting remote files

[Michael Albinus]

Deniz Dogan <deniz.a.m.dogan@gmail.com> writes:

> The first thing that I come to think of is what should happen should
> the request take longer than the interval. I'd like a feature which
> increases the interval automagically depending on how long requests
> take. It would also decrease the interval (but at no point go below
> the user set value) if the request takes less time than the current
> interval.

That would be an option. Another approach could be not to revert the
file, if the previous revert operation has not finished yet. This would
work without magical adaption of the interval.

Best regards, Michael.

Re: autoreverting remote files

[Stefan Monnier]

> That would be an option. Another approach could be not to revert the
> file, if the previous revert operation has not finished yet. This would
> work without magical adaption of the interval.

Or rather than revert every N seconds, we could simply wait N seconds
between each revert.


        Stefan

Re: autoreverting remote files

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> That would be an option. Another approach could be not to revert the
>> file, if the previous revert operation has not finished yet. This would
>> work without magical adaption of the interval.
>
> Or rather than revert every N seconds, we could simply wait N seconds
> between each revert.

Yes. I also would like to optimize autorevert. Today, it always reads
the whole file, which is bad for LARGE files. Just reading the last
lines would be OK for something like auto-revert-tail-mode.

Or even only applying tail -f (which does work already, if you select a
file in a dired buffer, and then apply "! tail -f * &").

>         Stefan

Best regards, Michael.

Re: autoreverting remote files

[Stefan Monnier]

> However, there are use cases where it might be acceptable to handle
> remote files, too. For example, watching a log file via
> `auto-revert-tail-mode', which can be accessed as root only.

If it's accessed via Tramp over su/sudo, then one could argue that the
file is not remote.


        Stefan

Re: autoreverting remote files

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> However, there are use cases where it might be acceptable to handle
>> remote files, too. For example, watching a log file via
>> `auto-revert-tail-mode', which can be accessed as root only.
>
> If it's accessed via Tramp over su/sudo, then one could argue that the
> file is not remote.

Sure. But `file-remote-p' does not know the difference.

>         Stefan

Best regards, Michael.

Re: autoreverting remote files

[Stefan Monnier]

>>> However, there are use cases where it might be acceptable to handle
>>> remote files, too. For example, watching a log file via
>>> `auto-revert-tail-mode', which can be accessed as root only.
>> 
>> If it's accessed via Tramp over su/sudo, then one could argue that the
>> file is not remote.

> Sure. But `file-remote-p' does not know the difference.

Not true: file-remote-p delegates the job to Tramp, and Tramp does know.


        Stefan

Re: autoreverting remote files

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Sure. But `file-remote-p' does not know the difference.
>
> Not true: file-remote-p delegates the job to Tramp, and Tramp does know.

We've discussed it a year ago. file-remote-p is also used for
implementation dependent decisions; what we need is something like
"file-access-is-slow-p", which could also be true even for "local"
files, if they are mounted, or because they are extremely HUGE.

Anyway, this is another discussion. I wanted to know whether I could
change autorevert.el; I haven't seen objections until now :-)

>         Stefan

Best regards, Michael.

Re: autoreverting remote files

[Stefan Monnier]

>>> Sure. But `file-remote-p' does not know the difference.
>> Not true: file-remote-p delegates the job to Tramp, and Tramp does know.
> We've discussed it a year ago. file-remote-p is also used for
> implementation dependent decisions; what we need is something like
> "file-access-is-slow-p",

AFAIC, file-remote-p is exactly what you call "file-access-is-slow-p".

> which could also be true even for "local" files, if they are mounted,

They're all "mounted", so I guess you mean "mounted from a remote
server", in which case file-remote-p should indeed return non-nil (tho
this is not implemented yet).

> or because they are extremely HUGE.

This seems to be out of the scope of file-remote-p (or
file-access-is-slow-p), and is already well served by file-attributes,
I believe.

> Anyway, this is another discussion. I wanted to know whether I could
> change autorevert.el; I haven't seen objections until now :-)

It looks like a fine idea, yes.

BTW, I don't understand why file-remote-p is checked in
auto-revert-handler rather than in (global-)auto-revert-(tail-)mode.
It's not like the remoteness of a buffer is going to change, is it?
It would also make it possible for the user to force auto-revert-mode in
some specific buffer even if the file is remote.


        Stefan

Re: autoreverting remote files

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Anyway, this is another discussion. I wanted to know whether I could
>> change autorevert.el; I haven't seen objections until now :-)
>
> It looks like a fine idea, yes.
>
> BTW, I don't understand why file-remote-p is checked in
> auto-revert-handler rather than in (global-)auto-revert-(tail-)mode.
> It's not like the remoteness of a buffer is going to change, is it?
> It would also make it possible for the user to force auto-revert-mode in
> some specific buffer even if the file is remote.

For the time being, I have enabled auto-revert-tail-mode for remote
files. That seems to be the most wanted functionality.

I've also changed the implementation of Tramp's insert-file-contents,
that it copies only the requested characters, when BEG or END is
specified. This shall provide the needed speed.

The rest I haven't touched (yet); I want to wait for feedback first, if
any.

>         Stefan

Best regards, Michael.