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 drawbacks.
