🚀 go-pugleaf

Hello.

I am a happy Emacs user for several years now.

I don't know if the following is a bug of Emacs per se. But, I think
there is IS a grave misfeature/bug, which can confuse a user and put
him/her into panic mode somewhere, in the file saving/backup code in
case of file system overflow. I believe that with a little careful
programming against this possibility, we can cope better.

SHORT DESCRIPTION: A file was modified, and was saved, but lost when
the file system was full and the directory didn't have write
permission. I am not sure what was the culprit exactly. But, I hope
Emacs didn't lose the original file somehow.  (ADDED COMMNET:Now, it
seems that the ~/%backup%~ was created, but since its time stamp shows
that it was created and modified about a year ago,  I don't know if
I can trust it or not????)

Forgive me for the following confused writing. I haven't still
recovered from the shock and the panic that followed.

SCENARIO:
	System is SunOS. Emacs is 18.55 with Japanese patches. 

A file system is almost full (actually FULL). Only a super user can
write into that file system to use the additional remaining spill
space. (I think BSD-ish UNIX has this breathing space in case of file
system overflow. Only superuser or can write into this special spill
area [which is set aside at mkfs time] over the soft limit of the file
system capacity.)

	Now, a file in this directory was writable by a user because
of a group permission. However, the directory was only writable by
root: the listing that follows is AFTER someone changed the permission
after this event.

This user tries to rewrite this (not often rewritten) file and then
tries to save it in the directoy without becoming a superuser (he forgot).

Somehow the write failed. (And somehow the backup creation also
failed, but he didn't notice this, well he did notice something funny
when the autosave feature ran. "Backup failed, blah, blah...")  But,
He suddelny recalled that the directory is likely to be owned by root,
and the problem was related to protection issues, so didn't think much
about it, and said to himself, "Ok, I will become a superuser and
will try again."  He removed the modified buffer thinking that he
could always come back as superuser and rewrite the file.

	WRONG!!!  The file is removed/lost somehow and since backup
creation somehow failed, and he doesn't have the copy anymore! (Too
bad, he didn't realize the problem before he decieded to kill the
modified buffer, and then quite Emacs! Only after that, someone came to
his desk and asked if he tried to change the file. The original file
DID have write permission via group permission bit. Otherwise, he
would have realized the file was write protected and this would not
have happened.)
	
	Well the user was me, and the file was /etc/termcap! (As soon
as /etc/termcap was gone, many editors, and file viewers such as
versions of more stopped working unbeknownst to me. Since I didn't
quit Emacs for a while, I realized something WAS wrong when more
didn't show expected output...)

Important info.: Turns out /etc/termcap is a symbolic link to another
file.

ls -l /etc/termcap
lrwxrwxrwx  1 root           24 Aug 17  1990 /etc/termcap -> ../usr/share/lib/termcap

And the target file of the symbolic link was writable via group
permission.  In the listing below, it is NOT group-writable. It was changed
to avoid this mistake. (The listing is after the fact listing and not
show the status before the event, I am afraid.)

ls -lg /usr/share/lib
total 273
drwxr-sr-x  8 bin      staff         512 Aug 18  1990 ./
drwxr-sr-x  7 bin      staff         512 Aug 18  1990 ../
drwxrwsr-x  2 root     staff         512 Apr 25  1989 me/
drwxr-sr-x  2 bin      staff         512 Apr 25  1989 ms/
drwxr-sr-x  2 bin      staff         512 Apr 25  1989 tabset/
-rw-r--r--  1 root     staff      107980 Sep 11 19:04 termcap
-rw-rw-r--  1 root     staff      133832 Nov 22  1989 termcap.orig
drwxrwsr-x 43 bin      bin          1024 Nov 22  1989 terminfo/
drwxrwsr-x  2 root     staff         512 Nov 22  1989 tmac/
drwxr-sr-x  8 bin      staff        1536 Aug 17  1990 zoneinfo/


I am throughly confused why the file was lost. This is really strange.
(This can be a bug of saving/backing code when the file system is
FULL.)

Funny, my home directory contained much older remnant of %backup%~
(???)  so there was a time, this %backup% feature somehow worked... I
don't know why it was not created this time...  (ADDITIONAL COMMENT:
Or could this be the one created today??? Time stamp is certainly outdated.)

ls -lgtm ~/%*
-rw-rw-r--  1 ishikawa wheel      146715 Sep  6  1991 /usr2/ishikawa/%backup%~

RECOMMENDATION: I suggest that a little more elaborate (?) mechanism
be provided to make sure the file is NOT lost even in these (admitted
very dire and very rare) conditions... 
	Saving such emergency backup to /tmp, /var/tmp, /usr/tmp, or
even user specified directoies seems to be a good idea in anticipation
of possible file system overflow.(of course, user should be able to
turn on/off this feature since you don't want a personal letter or
important business doc left in these public directories. At least I
would like to see another directory or two tried other than ~/ ...) 

Anyway, my setting of relevant variables are:

backup-by-copying's value is nil

backup-by-copying-when-linked's value is nil

backup-by-copying-when-mismatch's value is nil

make-backup-files's value is t


PS: I asked one of the sysadmins here to make sure the termcap file is
put into regular backup (I am afraid that somehow this was not the
case. It was dumped to DAT when new OS was installed, so I could have
this one immediately...)

PPS: Can the one under ~/%backup%~ BE a emergency backup? I wonder why
it is not time stamped as created today. Enquiring mind wants to know.


 Chiaki Ishikawa,  Personal Media Corp.,  MY Bldg, 1-7-7 Hiratsuka,
 Shinagawa, Tokyo 142, JAPAN. FAX:+81-3-5702-0359, Phone:+81-3-5702-0351
 UUNET: ishikawa@personal-media.co.jp