On 5 September 2012 20:38, Haller, John H (John) <[email protected]> wrote: > I'm thinking this is more likely to be a network filesystem problem than > a mktemp problem. The OP reported that this was done in a large shared > filesystem. I would also guess that it is a NFS filesystem. If it is using > NFS v2, O_EXCL doesn't work properly, and mktemp won't be able to > properly check for collisions. O_EXCL should work for long-lived files, > though, as it is emulated by looking up whether the file exists. This is > a race-prone check, which can fail if two systems are both trying to > create the same filename. Given that AST mktemp already checks for > duplicates using O_EXCL, I don't see how AST mktemp could cause the > failure. While increasing the universe of filenames will decrease the > collision rate, it won't eliminate them. But, for NFS v2 to have caused > the problem, two programs would have had to created the same temp > file nearly simultaneously, although it's possible one created the file > long before it was used for writing anything and causing the corruption. > > A related problem would be if a program created a temp file with mktemp > long before it needed it, a temp cleaner removed the temp file, another > client created the temp file with the same name and used it, then the > first program came in and used the temp file it thought it had exclusively > opened long ago. This doesn't require a network filesystem problem, but > is an unusual use case such that a file is created long before it is actually > needed. But, given that a "temp" file needed to be kept in a directory for > over > 96 hours, this doesn't seem that unlikely.
We use NFSv4, which has stable semantics for O_EXCL. I think CERN has purged all NFSv2 and NFSv3 servers in 2011, the last one I saw was in 2009. I like to underline that NFSv2 (and in some extend NFSv3) is obsolete (and no longer usable in times of Gigabit Ethernet, per warning in Linux nfs(5)) and no new code should try to work around the shortcomings of such obsolete protocols. Lionel _______________________________________________ ast-users mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-users
