Quoting Henrik Grindal Bakken <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] wrote:
> > Quoting Henrik Grindal Bakken <[EMAIL PROTECTED]>:
> >> But as you said, that breaks hard-links (who has hard-links to such
> >> files anyway?). However, what if you first write to a temporary file,
> >> then to the real file, and unlink the temp file if the close() and all
> >> write()s to the real file succeeded?
> > Well, there are a few issues with this; one is that it introduces alot of
> > overhead, especially when saving over network.
> Well, these files are normally relatively small, aren't they?
Yeah, it's not an issue of bandwidth, but rather of latency. On high-latency
links (modem, satellite, etc) this will introduce a noticable delay, which will
be quite annoying - especially if the autosave-option is enabled.
> > Another is when one only has write-access to the data file and not
> > the parent directory, causing the creation of the tempfile to fail.
> Another possibility is to write the tempfile to /tmp. It will be deleted
> when the real file is closed, but until then, it's kept as a backup.
> Obviously, if the real write (or close) fails, the user must be told,
> so he can take some action and save off the tempfile somewhere.
True, but it may not be desirable for some users to have this data written to a
local harddrive. Even though the data file should be secure, some people may
prefer keeping the data file on a secure server and accessing it over network.
But I know I'm a bit difficult here - your suggestion is likely the most
reasonable solution to this problem, I just need to weigh it up against any