home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / gnu / emacs / bug / 1253 < prev    next >
Encoding:
Text File  |  1992-09-14  |  4.3 KB  |  95 lines
  1. Newsgroups: gnu.emacs.bug
  2. Path: sparky!uunet!cis.ohio-state.edu!ds5200.!ishikawa
  3. From: ishikawa@ds5200. (Chiaki Ishikawa)
  4. Subject: re: File lost in the face of overflowing file system
  5. Message-ID: <9209141133.AA06100@ds5200.local>
  6. Sender: gnulists@ai.mit.edu
  7. Reply-To: ishikawa@personal-media.co.jp
  8. Organization: GNUs Not Usenet
  9. Distribution: gnu
  10. Date: Tue, 15 Sep 1992 05:33:18 GMT
  11. Approved: bug-gnu-emacs@prep.ai.mit.edu
  12. Lines: 81
  13.  
  14. Dear Netter,
  15.  
  16. Here is a follow up to my own earlier posting about possible loss of a
  17. file under some dire conditions such as overflowing file system.
  18.  
  19. It turns out that *I* was wrong. The emergency backup WAS made. This
  20. posting is to try to clear up any confusion my misinformed message
  21. might have caused you.
  22.  
  23. >
  24. >Funny, my home directory contained much older remnant of %backup%~
  25. >(???)  so there was a time, this %backup% feature somehow worked... I
  26. >don't know why it was not created this time...  (ADDITIONAL COMMENT:
  27. >Or could this be the one created today??? Time stamp is certainly outdated.)
  28. >
  29. >ls -lgtm ~/%*
  30. >-rw-rw-r--  1 ishikawa wheel      146715 Sep  6  1991 /usr2/ishikawa/%backup%~
  31. >
  32. >PPS: Can the one under ~/%backup%~ BE a emergency backup? I wonder why
  33. >it is not time stamped as created today. Enquiring mind wants to know.
  34. >
  35.  
  36. Well, the modification date was time-stamped based on the modification
  37. time of the original file.  ls -lc showed that the file in question
  38. WAS produced on the day the mishap occurred. Agh.
  39.  
  40. Sorry for my premature posting and thank you, RMS, for pointing this
  41. out.
  42.  
  43. Also, RMS pointed out that setting file-precios-flag to non-nill will
  44. protect against I/O errors while saving files.  (I probably should
  45. create a list of files that ought to have this flag set to non-nil
  46. automatically when I visit it. Wonder if it is easy to steal some code
  47. from automode setup routine, etc.)
  48.  
  49. Now, however, I vividly recall that long time ago I changed and hacked
  50. the files.el code myself on a different version of Emacs on a
  51. different machine.  In case the user's home directory ALSO overflowed
  52. and ~/%backup%~ could not be created [this happened since my home
  53. directory on the machine was provided on a small disk, and major work
  54. was done under a directory on different disk! This time I was saved
  55. from the real disaster, but the last time it happened, I DID lose the
  56. file.] The modified code checked for the creation of ~/%backup%~ and
  57. created the backup under an alternate place in case something went
  58. amiss even under ~/%backup%~. (My modification didn't take care of the
  59. modification time time stamp feature very well, I think.) The files.el
  60. code (version 18.55) is not paranoia enough to check for this
  61. additional error.
  62.  
  63. I probably could hack again or take a look at the old save tape to see
  64. if I can still find it.  But, come to think of it, I should change the
  65. mod again so that a list of directories rather than a single fixed
  66. directory. A little progress at a time, I guess.
  67.  
  68. Also, I took a admittedly very brief look at how file-precious-flag is
  69. used in files.el and am not convinced yet if the situation I described
  70. can be handled well.  [I don't know very well the semantics of failure
  71. of file renaming, etc.. in case of file system overflow. The
  72. sematnical problem I had on a different machine from the one I use now
  73. was so different, I had to do it rather in a non-unix like way. I will
  74. try to see it by creating a dummy file and see how it would be handled
  75. by file-precious flag on my Sun machine.]
  76.  
  77. I won't be able to access computers for 4 days since I have to attend
  78. the exhibition called Data Show in Harumi, Tokyo for 4 days starting
  79. Wednesday. I will be at Ontario Booth there, I will let you know if I
  80. could hack up some of the ideas into Emacs Lispp code next week or the
  81. week after. (Why on earth at Ontario Booth you may be wondering since
  82. I am Japanese. If you come to the booth, you will find out :-))
  83.  
  84. If you are interested in my planned change or already have such
  85. changes, please let me know.(Since I am looking at 18.55 version of
  86. Emacs, I don't know if some changes are already made...)
  87.  
  88. Again, sorry for my misinformed posting. But, at least, it helped me
  89. to recall the old mods I did to avoid future disasters...
  90. -------
  91.  Chiaki Ishikawa,  Personal Media Corp.,  MY Bldg, 1-7-7 Hiratsuka,
  92.  Shinagawa, Tokyo 142, JAPAN. FAX:+81-3-5702-0359, Phone:+81-3-5702-0351
  93.  UUNET: ishikawa@personal-media.co.jp
  94.  
  95.