Talk:Make a backup file: Difference between revisions
→Atomicity: new section
(→Follow symlinks: bad symlink behaviour) |
(→Atomicity: new section) |
||
Line 44:
::Indeed. A simple application reading/writing files should not normally care (or check) if they are reading/writing via symlinks. The Go code for example is broken since it blindly assumes that any symlink doesn't point to another symlink. There are far too many ways to screw it up unless you really know what you're doing and you really understand symlinks (and how any specific user might choose to use them and want them to behave). IMO it shouldn't be an applications job to make file backups at all (except perhaps as an optional "feature" of an editor or some such; and for example editors like vim have a lot of options related to this so it will do what a user wants; assuming you can blindly lookup where a symlink points to and mess around in that directory is just bad). —[[User:dchapes|dchapes]] ([[User talk:dchapes|talk]] | [[Special:Contributions/dchapes|contribs]]) 14:00, 6 September 2014 (UTC)
== Atomicity ==
After coming back to this task... the requirements (stated requirements and to some degree implied requirements) stumble over the OS's support for atomic operations on a file system.
If atomicity is not an issue (if it's understood that the backup process may produce unintended consequences when some other mechanism is manipulating one or more of the path names being used to "backup" the file), the task is fairly straightforward.
If it is an issue, then all sorts of problems arise (for example, the file in question is on a network file system ...).
In a "real life" context this requires some sort of external attention (and redundancy -- backups being just one form of redundancy) to catch and recover from the occasional failures. Depending on the context, we wind up with quite a variety of cost/benefit issues.
So this winds up being a "best effort" problem, and many of the details are more about the underlying OS and hardware than about the language. It's an interesting problem. (But it's not a great fit as a rosettacode task.) --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 10:29, 19 July 2022 (UTC)
| |||