| |||||||||||||
XFS: the filesystem of the future?XFS: the filesystem of the future?Posted Mar 2, 2012 22:18 UTC (Fri) by mathstuf (subscriber, #69389)In reply to: XFS: the filesystem of the future? by dlang Parent article: XFS: the filesystem of the future?
The problem is that if the target is a symlink or a hardlink, it gets clobbered by this process and the link is destroyed. Applications that I use that do this are harder to use with my dotfiles system because of it (finch, gnupg, and others as well). What needs to happen is that the target file has readlink() done to its path to get the *actual* file that is wanted before this process starts.
(Log in to post comments)
XFS: the filesystem of the future? Posted Mar 2, 2012 23:33 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
doing an open, write, close on an existing file that is a hardlink may not be able to be atomic (depending on the size of the write, the hardware, etc) in any case.
so I think that your requirement results in error O_PONY
While something along the lines of what you are talking about may be able to be made to work in some more limited cases, arguing that it's a requirement because the temp-file approach doesn't work in all cases is a bad argument.
In fact, in the cases where the file is a symlink or hardlink, it's questionable as to what the 'right' think to do is.
In some cases you should follow the link and replace the 'master' file, but in other cases you should not. arguably, breaking the links is the safer thing to do (the system doesn't know what the effect of the changes are ot the other things accessing the file), but there's no question that sometimes you wish it did something different.
|
|||||||||||||