On Thu, 04 Mar 2010 15:52:58 +0100 Casper.Dik at Sun.COM wrote: > >On Thu, Mar 4, 2010 at 3:07 PM, <Casper.Dik at sun.com> wrote: > >> > >>>Can anyone from Sun please tell us why Bug 6932124 is locked? I cannot > >>>look it up via bugs.opensolaris.org > >> > >> I just filed it; I'm not sure why it would locked. > >> > >> This bug is this: > >> > >> $ mktemp log.2010-03-04.XXXXXX > >> log_2sie.t0f > > > >mktemp tries to fit its name into a 8.3 DOS naming.
> *why*? > It is clearly not compatible with the current implementation and some > scripts broke with the new ksh93 because of this. its wrong for the cases that run afoul of the standard in cases where the standard isn't involved (and it doesn't matter technically) its a choice made to minimize differences between ast implementations on different systems this is probably more than you wanted to know, but *why* is so open ended ... also, and this isn't an excuse for our bugs, an early ast design choice was/is to minimize function duplication across all of the functions in ast in this case we unified all of the tmp file creation functions into one (pathtemp()) (and apparently didn't do a good job with the mktemp(3) part of the unification -- that is being remedied today) now when tmp file problems crop up in the future we have only one piece of code to fix this happened with the tmp-file-predictability weakenesses uncovered a few years back (or was it a decade?)) having it all done in one place also opens up opportunities to balance tmp file loads, e.g., the TMPPATH environment var is a : separated list of directories where the first tmp file is attempted in the first dir, etc., wrapping back to the first dir when the list is exhausted right now its a simple circular list, but it could get smarter by monitoring free space on the corresponding filesystems -- Glenn
