eric> Unfortunately, I saw this a couple of weeks ago. I think eric> what happened to me was that I had a full file system. Then eric> I opened a file with XEmacs, modified it and tried to save eric> it. That resulted in the file being truncated to 0 bytes. eric> I was running under Red Hat 7.3. The default XEmacs save strategy is (1) rename the original to serve as backup; (2) write the buffer into the new file. As far as I know XEmacs does not attempt to overwrite existing data; the data is preserved under a different name. In the case at hand, you should get a "Writing file: No space left on device, /floppy/Notes" error. The last saved version of the file should still be there, renamed to the backup name. Quite likely there will be a recent autosave file containing most buffer modifications. Are any of these not true? Have you changed XEmacs's backup strategy? It's arguable that when the save fails, the partially saved file should be deleted and the backup file renamed to the original name. I don't like this for a couple of reasons. (1) The partial file may contain buffer modifications you would like to preserve. (2) You may not notice that you don't have a backup for this file anymore. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

Ville> IMHO, this produces somewhat unexpected (to me, anyway) Ville> results. When I edit a file, I want to change its Ville> contents, not modes or ownerships. Ville> Would it be possible to make Ville> `backup-by-copying-when-mismatch' default to t? We can talk about it, although my initial reaction is I don't like it. Copying is nonatomic and introduces some extra latency (eg, on NFS or TRAMP edits). It also has the severe disadvantage (to my mind) that in the case at hand, your backup has been destroyed but you don't know that unless you're thinking about it carefully. If you should need it, you have an unpleasant surprise waiting for you. With the default, what should happen is that (1) disk full causes the save to fail (2) you have an unpleasant surprise that the file on disk is truncated (3) you have the pleasant surprise that the backup is actually current. If you're lucky (or been there before :-), you preserved the buffer, so you have _all_ the most recent data. Furthermore, you know you're at risk, so you take extra care. I like that scenario a _lot_ better. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.