Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!purdue!mentor.cc.purdue.edu!j.cc.purdue.edu!nwd
From: nwd@j.cc.purdue.edu (Daniel Lawrence)
Newsgroups: comp.emacs
Subject: Re: UEmacs 3.10
Summary: uEMACS SSAVE
Keywords: UEmacs, file permissions
Message-ID: <10325@j.cc.purdue.edu>
Date: 10 Nov 89 16:08:51 GMT
References: <440@secola.Columbia.NCR.COM> <1592@crdos1.crd.ge.COM>
Reply-To: nwd@j.cc.purdue.edu (Daniel Lawrence)
Organization: Purdue University
Lines: 40

In article <1592@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes:
>>[  problem losing file ownership and permissions  ]
>
>  This is the SAFESAVE option. I reported it as a possible problem when
>it first came out, and I haven't changed my mind.

	[ Some reasonable valid reasons for not using $ssaveing]

>Opinion: this option made sense in the days of CP/M and Apple ][, with
>small and unreliable floppy disks. It doesn't make sense for me in any
>environment, and causes tons of problems in the cases listed above. I
>suggested that the default source be shipped with the option off and
>some cautionary wording in the manual, but I haven't looked to see if
>that happened.

>bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)

	True, there are reasons for not using ssaving, but the worst
that happens when using it is that the files get the wrong permissions,
and or links get confused.  If the temp file write fails on disk space
uEMACS will also chime up with an error message and leave you editing...
ie you can shell and fix the problem.

	If you should have been using it, and don't, then the worst that
happens is that you destroy your original file and don't get your new
file written out.  After a few times of this happening to people, I
decided to make it the default.  Mind you, I have absolutly no problem
with people dropping a

	set $ssave FALSE

	in their startup files.  That's what they are for.  But I do
want the default shipped behavior to be consistant across all platforms,
and I consider the problem of loosing files completely more immediate
than that of bad permissions.

			Daniel Lawrence  voice: (317) 742-5153
					  arpa:	dan@midas.mgmt.purdue.edu
				The Programmer's Room 
				Fido: 1:201/10 - (317) 742-5533