Valerie Aurora wrote: > I'm working on the assumption that this is okay. Basically, an > in-kernel copyup has the same effect on an application with an > O_RDONLY fd as a userland copy-up to a temporary file followed by a > rename() to the original name. Editors, among other applications, use > this sequence all the time. If it breaks under union mount copyup, it > will also break if you edit the file with vi. Ouch. That's fine for rename-over style updates, but if an application depends on in-place updates, or if it depends on file locking to serialise something (using O_RDONLY for read locks and O_RDWR for write locks), it will get confused. Now, that may be acceptable compromise non-POSIX behaviour. But if it only works with rename-over style updates.... Why have in-kernel copyup at all? Why not simply forbid writes to lower files? Rename-over updates will be fine with that, and there'll be no unexpected long delays to do copyup of a huge file. -- Jamie -- 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
