On Mon, Sep 17, 2012 at 3:40 AM, Glenn Fowler <g...@research.att.com> wrote:
> On Sun, 16 Sep 2012 23:40:35 +0200 Roland Mainz wrote:
>> While looking at the issues around temporary files I noticed that some
>> shell scripts create a lot of temporary files...
>> ... which leads to the question: Wouldn't it be better to create one
>> temporary directory with a random name and then create all temporary
>> files in that directory ?
>
>> AFAIK the advantages are:
>> - This should be faster in cases that /tmp is clogged with thousands
>> of files. I've seen that in some caases /tmp on Solaris can have
>> 50000+ actively used files (not all from ksh93) ... which borders IMO
>> near insanity to handle that (usual suggestion is to set TMPDIR to
>> something like /tmp/$LOGNAME/ in /etc/profile). This assume we open
>> the directory using |openat()| to avoid that the shell always needs to
>> do a full path lookup starting from ${TMPDIR}.
>> - The files in the temporary directory can be picked in a more
>> descriptive fashion, e.g. made out of
>> "l<lineno>n<namespace>f<functionname>s<subshelllevel>p<pid>c<counter>t<timestamp>.tmp"
>> (namespace, functionname and subshelllevel are only used if
>> appiliable/used and "counter" is an |uint64_t| which is increased for
>> each temporary file. The <pid> part names sure this is unique even if
>> a subshell called |fork()| and then fork'ed child processes) or
>> something like that.
>
>> Disadvatages:
>> - It's harder to delete the directory
>> - At least one extra syscall is required (|mkdir()|)
>> - More code, making ksh93 bigger
>
> - predictabilityWell, I can add "not appliciable" here, too. I had the same idea two years ago when I crawled over the code and was half through and send a similar email. After crawling over the remainder of the code I remembered that temporary files for x=$(...) are unlinked directly after creation to make them inaccessible. 24 months later I did the same mistake... grrrr... ;-( Sorry... ;-( ---- Bye, Roland P.S.: That's a reason for having a bugzilla... file all half-mad ideas and reject them myself so I can search for them a few years later when I have another brilliant-but-dumb inspiration at 2h AM again... ;-) -- __ . . __ (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
