Re: auto-saving and jka-compr-write-region

Doing auto-saves locally helps a lot with the speed, so I presume
you're happy with me trying that.
Yes, and that's also why the auto-save file should not be compressed.
Do you have some suggestion what I should do about the ".gz" suffix
on the filename?
Either remove the suffix, or do something else so that the file is
auto-saved without compressing it.
I think that maybe just removing the suffix is not
such a good idea since people might wish to edit both the file
/[kai@...]/tmp/foo and the file /[kai@...]/tmp/foo.gz in
the same Emacs session. Removing the suffix would mean that one
auto-save file overwrites the other one.
That is not as bad a problem as compressing during every auto-save.
Besides, you can find some other way to uniquify the auto-save file
names.

Thread view

In fileio.c, function auto_save_1, I see that `write-region' is called
with nil for START and END. But if the filename handler for that file
(the autosave file) is jka-compr, then jka-compr-write-region barfs
because it assumes the values to be numbers, not nil.
Is it dangerous to use a *.gz file as an autosave file, or should
this work?
Should jka-compr-write-region grok START and END being nil? If so,
how should that be achieved?
This comes about because Tramp arranges to set the auto-save file name
for a buffer to be a filename with *.gz, if the filename of the buffer
was *.gz. Maybe Tramp shouldn't do this, but I get the feeling it
ought to work.
kai
--
Simplification good! Oversimplification bad! (Larry Wall)

Is it dangerous to use a *.gz file as an autosave file, or should
this work?
It seems bizarre to try that, given that you want autosaves to be
fast above all. If there's a simple safe fix to make it work,
we may as well make it work. But it is not terribly important.
This comes about because Tramp arranges to set the auto-save file name
for a buffer to be a filename with *.gz, if the filename of the buffer
was *.gz. Maybe Tramp shouldn't do this, but I get the feeling it
ought to work.
It is definitely wrong for Tramp to do this. Can you please
ask the maintainer of Tramp to change that?

Richard Stallman <rms@...> writes:
> Is it dangerous to use a *.gz file as an autosave file, or should
> this work?
>
> It seems bizarre to try that, given that you want autosaves to be
> fast above all. If there's a simple safe fix to make it work,
> we may as well make it work. But it is not terribly important.
OK.
> This comes about because Tramp arranges to set the auto-save file name
> for a buffer to be a filename with *.gz, if the filename of the buffer
> was *.gz. Maybe Tramp shouldn't do this, but I get the feeling it
> ought to work.
>
> It is definitely wrong for Tramp to do this. Can you please
> ask the maintainer of Tramp to change that?
That would be me :-)
Tramp allows you to edit remote files. Tramp includes a feature where
you can set a variable so that auto-saves are done locally. Suppose
that the tramp-auto-save-directory is "~/.tramp", then the auto-save
file for /[kai@...]/tmp/foo.gz would be
~/.tramp/[kai@...]/tmp/foo.gz, except that some potentially
dangerous characters (such as "[]") are replaced with something else
("_a" and "_b" in this case).
Doing auto-saves locally helps a lot with the speed, so I presume
you're happy with me trying that.
Do you have some suggestion what I should do about the ".gz" suffix
on the filename? I think that maybe just removing the suffix is not
such a good idea since people might wish to edit both the file
/[kai@...]/tmp/foo and the file /[kai@...]/tmp/foo.gz in
the same Emacs session. Removing the suffix would mean that one
auto-save file overwrites the other one.
Also, including special cases for jka-compr in Tramp means that Tramp
might have to know about all the other filename handlers out there.
I guess this is not such a good idea.
I could replace "." in the file name with "_d", that would disable
jka-compr for the auto-save file.
kai
--
Simplification good! Oversimplification bad! (Larry Wall)

Doing auto-saves locally helps a lot with the speed, so I presume
you're happy with me trying that.
Yes, and that's also why the auto-save file should not be compressed.
Do you have some suggestion what I should do about the ".gz" suffix
on the filename?
Either remove the suffix, or do something else so that the file is
auto-saved without compressing it.
I think that maybe just removing the suffix is not
such a good idea since people might wish to edit both the file
/[kai@...]/tmp/foo and the file /[kai@...]/tmp/foo.gz in
the same Emacs session. Removing the suffix would mean that one
auto-save file overwrites the other one.
That is not as bad a problem as compressing during every auto-save.
Besides, you can find some other way to uniquify the auto-save file
names.

Richard Stallman <rms@...> writes:
> Doing auto-saves locally helps a lot with the speed, so I presume
> you're happy with me trying that.
>
> Yes, and that's also why the auto-save file should not be compressed.
Right.
> Do you have some suggestion what I should do about the ".gz" suffix
> on the filename?
>
> Either remove the suffix, or do something else so that the file is
> auto-saved without compressing it.
I have now appended "~" to the auto-save filename.
But I do not feel happy with this solution. I get the feeling that it
is something which will work fine for a long time, and some years
later, when nobody remembers what might be happening, it will bite us
again. However, I can't really substantiate my claims with rational
arguments; it's just a gut feeling.
What do people think: should this issue be done _right_, or just in a
way that works for now?
kai
--
Simplification good! Oversimplification bad! (Larry Wall)

What do people think: should this issue be done _right_, or just in a
way that works for now?
What aspect of my proposal do you think is not right?
What would make it more right? You can't improve it without
first answering that.

Richard Stallman <rms@...> writes:
> What do people think: should this issue be done _right_, or just in a
> way that works for now?
>
> What aspect of my proposal do you think is not right?
> What would make it more right? You can't improve it without
> first answering that.
Let me recap the problem, since it's been a while. The problem was
that Tramp has a feature which requests auto-save files to be saved
locally. But this feature led to auto-save filenames which triggered
jka-compr (if the original file was a compressed file), and
jka-compr-write-region does not want to be called with nil for START
and END, but auto_save_1 does just that.
I have now done the following:
First, Tramp converts the remote file name, for example
/[user@...]/path/to/file
into a local file name, for example
~/.tramp/_l_user@.../path/to/file
Then, Tramp invokes make-auto-save-file-name on this file, leading to
~/.tramp/_l_user@.../path/to/#file#
And this correctly leads to jka-compr not being invoked, even if the
file was something like foo.gz.
kai
--
Simplification good! Oversimplification bad! (Larry Wall)

Richard Stallman <rms@...> writes:
> Are you saying the problem is solved now?
> I think so, please confirm.
That's right, auto-save now works correctly with Tramp and
auto-compression-mode enabled. It works both locally (auto-saves for
remote files go on the local host) and remotely (auto-saves for
remote files go on the same remote host).
The fact that jka-compr-write-region still doesn't grok nil as START
and END remains, of course. But it doesn't actually break Tramp
anymore.
kai
--
Simplification good! Oversimplification bad! (Larry Wall)