On 5 September 2012 19:41, Glenn Fowler <[email protected]> wrote: > > On Wed, 5 Sep 2012 18:48:00 +0200 Lionel Cons wrote: >> On 5 September 2012 17:00, Glenn Fowler <[email protected]> wrote: >> > >> > (1) are we talking about libast mktemp(3) or ksh mktemp(1) > >> AST mktemp as plain command. We replaced the machine's native >> /usr/bin/mktemp with AST mktemp since GNU coreutils and (especially!) >> the Solaris /usr/bin/mktemp are prone to even more collisions (Solaris >> mktemp in Solaris 2.6-10 and 11 (Opensolaris didn't have the problem >> since it used the ksh93 mktemp) suffers from printing random garbage >> in rare occasions, too). > >> > (2) did the original temp file exist when the dup name was generated > >> I don't know. I have to ask. I'm just the messenger. > > roland is correct that the low level ast routine is pathtemp() > > the reason for question (2) is that pathtemp() has a collision detection loop > and mktemp(1) calls pathtemp() with an fd pointer that instructs it to > create the temp file with > open(path, O_CREAT|O_RDWR|O_EXCL, mode) > if this fails then another pseudo-random tmp path is generated > until there is no collision > > even if the range of the generated paths were limited pathtemp(3) as called > by mktemp(1) should never return success on a path that already exists > unless mktemp were called with --unsafe or with --directory > > pathtemp() in this mode could fail (by not returning) if the entire range > were covered by existing files -- it would loop in a bad fashion, attempting > random paths attempting to hit unused names > > since the collision in your case was after 96 hours I don't think its > any kind of weird filesystem timing problem > > can you send the mktemp command line used?
backrunner[run].fname=$(/opt/ast/bin/mktemp) Lionel _______________________________________________ ast-users mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-users
