On 23 March 2018 at 16:28, Seebs <[email protected]> wrote: > On Fri, 23 Mar 2018 17:10:35 +0100 > Enrico Scholz <[email protected]> wrote: > >> I think, 'mv' is the culprit. It calls 'renameat2()' directly over >> 'syscall()': >> >> | $ ltrace mv foo bar >> | ... >> | syscall(316, 0xffffff9c, 0x7fff1564a341, >> 0xffffff9c) = 0 >> >> >> Perhaps, 'pseudo' does not catch this? > > Yeah. > > And so far as I know, it's not actually *possible* to in the general > case. I really don't think it's safe to try to catch syscall(). > > I was afraid someone would do this. (It also breaks most Go programs, > for similar reasons; no libc calls.) > > I have no idea why they're doing that; it seems distinctly unsafe.
Because in GNU's infinite wisdom they're using renameat2() to do atomic renames in the mv command, and as renameat2 isn't in the headers for F27 it just does a syscall directly. This is in upstream coreutils so once they make a release, everyone gets it. This is really ruining my day. Ross -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
