🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.emacs.bug
Article #675

re: File lost in the face of overflowing file system

#675
From: ishikawa Chiaki Ishikawa
Date: Tue, 15 Sep 1992 05:33
80 lines
4493 bytes
Dear Netter,

Here is a follow up to my own earlier posting about possible loss of a
file under some dire conditions such as overflowing file system.

It turns out that *I* was wrong. The emergency backup WAS made. This
posting is to try to clear up any confusion my misinformed message
might have caused you.

>
>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%~
>
>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.
>

Well, the modification date was time-stamped based on the modification
time of the original file.  ls -lc showed that the file in question
WAS produced on the day the mishap occurred. Agh.

Sorry for my premature posting and thank you, RMS, for pointing this
out.

Also, RMS pointed out that setting file-precios-flag to non-nill will
protect against I/O errors while saving files.  (I probably should
create a list of files that ought to have this flag set to non-nil
automatically when I visit it. Wonder if it is easy to steal some code
from automode setup routine, etc.)

Now, however, I vividly recall that long time ago I changed and hacked
the files.el code myself on a different version of Emacs on a
different machine.  In case the user's home directory ALSO overflowed
and ~/%backup%~ could not be created [this happened since my home
directory on the machine was provided on a small disk, and major work
was done under a directory on different disk! This time I was saved
from the real disaster, but the last time it happened, I DID lose the
file.] The modified code checked for the creation of ~/%backup%~ and
created the backup under an alternate place in case something went
amiss even under ~/%backup%~. (My modification didn't take care of the
modification time time stamp feature very well, I think.) The files.el
code (version 18.55) is not paranoia enough to check for this
additional error.

I probably could hack again or take a look at the old save tape to see
if I can still find it.  But, come to think of it, I should change the
mod again so that a list of directories rather than a single fixed
directory. A little progress at a time, I guess.
 
Also, I took a admittedly very brief look at how file-precious-flag is
used in files.el and am not convinced yet if the situation I described
can be handled well.  [I don't know very well the semantics of failure
of file renaming, etc.. in case of file system overflow. The
sematnical problem I had on a different machine from the one I use now
was so different, I had to do it rather in a non-unix like way. I will
try to see it by creating a dummy file and see how it would be handled
by file-precious flag on my Sun machine.]

I won't be able to access computers for 4 days since I have to attend
the exhibition called Data Show in Harumi, Tokyo for 4 days starting
Wednesday. I will be at Ontario Booth there, I will let you know if I
could hack up some of the ideas into Emacs Lispp code next week or the
week after. (Why on earth at Ontario Booth you may be wondering since
I am Japanese. If you come to the booth, you will find out :-))

If you are interested in my planned change or already have such
changes, please let me know.(Since I am looking at 18.55 version of
Emacs, I don't know if some changes are already made...)

Again, sorry for my misinformed posting. But, at least, it helped me
to recall the old mods I did to avoid future disasters...
-------
 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
Technical Details
Message-ID: <9209141133.AA06100@ds5200.local>
Path: arc1-ca.pugleaf.net!sparky!uunet!cis.ohio-state.edu!ds5200.!ishikawa

Show Full Headers
Complete Article Headers
Newsgroups: gnu.emacs.bug
Path: arc1-ca.pugleaf.net!sparky!uunet!cis.ohio-state.edu!ds5200.!ishikawa
From: ishikawa@ds5200. (Chiaki Ishikawa)
Subject: re: File lost in the face of overflowing file system
Message-ID: <9209141133.AA06100@ds5200.local>
Sender: gnulists@ai.mit.edu
Reply-To: ishikawa@personal-media.co.jp
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Sep 1992 05:33:18 GMT
Approved: bug-gnu-emacs@prep.ai.mit.edu
Lines: 81