From: Kai.Grossjohann@CS.Uni-Dortmund.DE (K. ) - 2001-12-06 17:47:38
|
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) |
From: Richard S. <rm...@gn...> - 2001-12-07 07:11:08
|
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? |
From: Kai.Grossjohann@CS.Uni-Dortmund.DE (K. ) - 2001-12-07 11:00:12
|
Richard Stallman <rm...@gn...> 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@otherhost]/tmp/foo.gz would be ~/.tramp/[kai@otherhost]/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@otherhost]/tmp/foo and the file /[kai@otherhost]/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) |
From: Richard S. <rm...@gn...> - 2001-12-10 03:02:53
|
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@otherhost]/tmp/foo and the file /[kai@otherhost]/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. |
From: Kai.Grossjohann@CS.Uni-Dortmund.DE (K. ) - 2001-12-10 09:59:08
|
Richard Stallman <rm...@gn...> 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) |
From: Richard S. <rm...@gn...> - 2001-12-11 07:15:05
|
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. |
From: Kai.Grossjohann@CS.Uni-Dortmund.DE (K. ) - 2001-12-28 21:02:33
|
Richard Stallman <rm...@gn...> 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@host]/path/to/file into a local file name, for example ~/.tramp/_l_user@host_r_/path/to/file Then, Tramp invokes make-auto-save-file-name on this file, leading to ~/.tramp/_l_user@host_r_/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) |
From: Richard S. <rm...@gn...> - 2001-12-29 20:34:59
|
Are you saying the problem is solved now? I think so, please confirm. |
From: Kai.Grossjohann@CS.Uni-Dortmund.DE (K. ) - 2001-12-30 17:34:45
|
Richard Stallman <rm...@gn...> 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) |