On Thu, 6 Sep 2012 22:35:11 +0200 Lionel Cons wrote: > On 5 September 2012 18:48, Lionel Cons <lionelcons1...@googlemail.com> wrote: > > On 5 September 2012 17:00, Glenn Fowler <g...@research.att.com> 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.
> The file did not exist. The script in question created the temporary > file name in a different directory and moved it after content > validation into a different directory to mark it's 'readiness' for > further processing. The collision occurred at backup level where the > design of the software assumed that all incoming data files have > unique names (so the cp used trashed older data). Given the 1PB/week > throughput this assumption was pretty dumb. ok, the problem is understood on both sides > My request still stands: Please make, if the filesystem allows it, the > unique filenames returned by AST mktemp much *longer*. I'd like to > have a safeguard against the dumb people in my staff. I've already tested a change to libast::pathtemp() that will default to 10 chars in [0-9a-zA-Z] mktemp --directory also changed to let pathemp() do the mkdir(2) thanks for inspiring the code review _______________________________________________ ast-developers mailing list ast-developers@research.att.com https://mailman.research.att.com/mailman/listinfo/ast-developers
