On Mon, 25 February 2013 13:14:52 -0800, Andy Lutomirski wrote: > > I thought the first thing people would ask for is to atomically create a > new file and copy the old file into it (at least on local file systems). > The idea is that nothing should see an empty destination file, either > by race or by crash. (This feature would perhaps be described as a > pony, but it should be implementable.) Having already wasted many week trying to implement your pony, I would consider it about as possible as winning the lottery three times in a row. It clearly is in theory and yet,... If you take a filesystem like ext[34] you are out of luck. In those filesystems it may not even be theoretically possible to get the cleanup right for pathological cases. And if you ignore pathological cases and depend on userspace to do the cleanup for you, you have to do ABI extentions that I don't want to mention with Al on Cc:. My personal notebook ran such a kernel for several years until hardware improved to a point that I no longer wanted to forward-port the patches. It worked but it was far from pretty. If you have a filesystem where you can simply bumb a reference count to copy the file content, implementation is fairly straightforward. But having a system call that is effectively limited to btrfs means pretty much noone will use it - beside the people looking for potential kernel exploits. So my vote clearly goes to some variant of sendfile or splice. Jörn -- Man darf nicht das, was uns unwahrscheinlich und unnatürlich erscheint, mit dem verwechseln, was absolut unmöglich ist. -- Carl Friedrich Gauß -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
