| Michael Paoli 2006-05-12, 10:00 pm |
| Brian Raiter wrote[1]:
> I'm afraid I'd have to argue that keeping the temporaries "next to"
> the original is actually the better practice when it comes to the
> other two points I've quoted above. If you keep all your temporaries
> in one place, then you increase the likelihood of naming conflicts
> (from two people editing different files with the same filename),
> making it harder for casual users to see which temporary goes to which
> file after a crash. Keeping the temporary "next to" the original means
> that naming clashes occur only when people are (potentially) modifying
> the same file anyway. emacs follows this path, and so it is easy for
> me to tell when a temporary emacs file has been left behind, and emacs
> does not rely on other data in order to resume from an autosave.
>
> Of course these issues become unimportant in situations where you know
> you will not have multiple simultaneous users, but that is the
> exception.
Well, I beg to differ, on at least several of your points:
o "Naming conflicts" should not be an issue, e.g. with temporaries in
a "common" location, and/or multiple instances of editor working on
identically named file at the same time (with the same or distinct
pathnames). This is mostly dealt with via proper temporary file
handling[2]. This is essentially a "solved" problem in
UNIX(/LINUX, etc.) ... of course that doesn't mean folks don't
repeatedly make the same mistakes when it comes to programming
(e.g. BUGTRAQ[3] provides tons of examples of the same classic
mistakes made over and over again).
o Casual users don't need to "see" which temporaries are associated
with editing sessions on which files. Granted, for the casual
user, seeing something quite similarly named there alongside the
original may help give them more suitable hints, but that can also
lead to more problems (e.g. they think it's cruft and remove it,
not realizing they actually want to make use of it, or they remove
it or overwrite it or truncate it while it's open and in use by the
editor, or there's a naming conflict if the naming convention is
too limited, etc. - those problems are mostly avoided when the
temporaries are in suitable common temporary location(s).). Having
suitable means to find out there's a "recovery" file (abnormally
terminated edit session), and how to recover is usually pretty
sufficient (e.g. editor sends user e-mail informing them of the
fact and how to recover, basic training/documentation on the editor
covers how to check if there are recovery files and how to recover,
etc.).
o This is UNIX, etc., one must presume that various asynchronous
events may and will generally occur (same or other users editing
identically named file or pathname at the same time, any sequence
of non-atomic events may have other events occur between them or
the latter events may not even occur (e.g. abnormal termination),
one must take suitable precautions to avoid problematic race
conditions (e.g. proper handling of temporaries. And placing
temporaries alongside the original does not eliminate potential
race conditions, e.g. in a shared drwxrwx--T directory (with or
without any and/or all of sticky bit, SGID, world "execute" and/or
world read on directory) two distinct users could generally breach
the security of each other's accounts if temporary files are
written in that directory and the security of such isn't properly
handled. Even in a non-shared directory, a user could
unintentionally clobber or corrupt their own work if temporaries
aren't handled properly).
I certainly tend to be of the opinion that how we do our penultimate
operations to have the edited data end up at the original pathname is
much more debatable[4], but that the case of where the temporaries
should go - at least generally speaking - is relatively clear cut (or
at least makes for a rather lopsided debate).
footnotes/references:
1. in news:e3tu6e$8ej$1@cascadia.drizzle.com
and left out some attribution information:
news:1147034979.155446.109330@v46g2000cwv.googlegroups.com
2. e.g. see:
http://www-128.ibm.com/developerwor...ace.html#N10174
and numerous similar qualified reference materials.
3. http://www.securityfocus.com/archive/1
4. news:1147162629.287269.146060@e56g2000cwe.googlegroups.com
news:comp.security.unix
|