On Wed, Sep 5, 2012 at 5:00 PM, Glenn Fowler <g...@research.att.com> wrote: > On Wed, 5 Sep 2012 12:53:33 +0200 Lionel Cons wrote: >> Glenn, by chance or bad luck one of our production runs trashed older >> data (which resulted in severe dataloss problems. We DO have backups, >> but it may take months to recover from this). After a lengthy search >> we traced the problem down to the issue that AST mktemp generated the >> same temporary file names twice, almost exactly 96 hours apart. I >> don't know how or why (my staff is still looking), but I was told the >> default name length is insufficient for large, shared file systems >> which receive almost 2000 mktemp calls per minute from different >> machines. Sourly I've recognised that the problem is known by POSIX, >> as http://pubs.opengroup.org/onlinepubs/000095399/functions/mkstemp.html >> dryly remarks it's "possible to run out of letters". Yay. > >> My request would be to increase the default temporary file name length >> returned by the AST mktemp command if the filesystem supports this. > > (1) are we talking about libast mktemp(3) or ksh mktemp(1)
Just guessing... but a lot of the data stuff uses scripts... my guess it's the ksh93 builtin mktemp(1). > (2) did the original temp file exist when the dup name was generated Mhhh... I thought a bit about Lionel's problem and looked at the |pathtemp()| code... one possible improvement would be to use the ppid of the current process in the hash, too (and maybe even the ppid of that ppid...if there is an easy way to get it (or maybe the process group id ? $PID/$PPID/$PGRPID with 32bit each would give 96bits of hash input data. Maybe if there is a way to get the maxpid value when the values could be shifted together to avoid having too much upper zero bits)). The issue is that if AST mktemp is an external process then the current pid used in the hash will be short-lived while the ppid is likely to be longer around (still doesn't help with Lionel's issue). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.ma...@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ ast-developers mailing list ast-developers@research.att.com https://mailman.research.att.com/mailman/listinfo/ast-developers
