Article View: gnu.emacs.bug
Article #675re: File lost in the face of overflowing file system
From: ishikawa Chiaki Ishikawa
Date: Tue, 15 Sep 1992 05:33
Date: Tue, 15 Sep 1992 05:33
80 lines
4493 bytes
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.!ishikawaShow 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