On Thu, 07 May 2009, Kenneth Ölwing wrote:
>  I guess this is mostly aimed at Jan, but I'm sure someone else could
>  have useful input...

Yes, please!

>  Before filing a bug/improvement request I figured it could be useful
>  to get some pre-response here...:-)
> 
>  I seem to recall discussion about this flag a couple of years back,
>  but it hasn't really been something I needed to care about.

There was a thread about adding environment variable expansion into
--tmpdir arguments in this thread:

http://aspn.activestate.com/ASPN/Mail/Message/pdk/1391126

But it turned out that adding the user name to the standard temp
directory name would solve that particular problem in a better way.

>  However, I now have some considerations that would be helped by
>  'improving' it a bit.
> 
>  I have a fairly large perlapped application that I distribute
>  internally. A hundred or more users, all working on 30-40 'servers',
>  desktop machines etc, collectively a variety of platforms (Linux,
>  Windows, Solaris, 32/64 bits etc etc) are involved. The app contains a
>  fairly large number of extra modules, many with .so/.dll files, so
>  they need to be unpacked while in use - I regularly add/update to new
>  versions, so new md5'ed copies will show up.
> 
>  Now, this all works well. But what I would like to do would be to get
>  a better grip of the numerous 'pdk-user' dirs that are used for the
>  caching of unpacked data, since I don't want them littering /tmp on
>  the common servers for all eternity. Silly thing perhaps, but given
>  our environment this is something users have asked about and there are
>  other reasons for us to keep /tmp et al as 'clean' as possible. (Yes,
>  --dyndll is in use but only relevant for Windows, --clean is not
>  desirable - the caching makes sense etc).

I don't know, people who like to keep their /tmp directories clean
should probably reboot their machines more often and wipe /tmp
totally empty on restart.  Or run a cron job that deletes files older
than 90 days from /tmp every week or something like that.

>  One way to collect them would be to set the TMPDIR or TEMP envvar
>  beforehand - but this is not something I can realistically control for
>  all users. Another simple and effective way for me to control them
>  better, would be if I could use --tmpdir to ensure they get put under
>  a common root. However, the current impl is very limited - it requires
>  hardcoding a dir and that it should exist beforehand; also not
>  something I can realistically control everywhere.

If you cannot control the user configuring their system correctly for
your application, how can you be sure that writing to the "common root"
directory is going to work? You may not even have write access to it on
some machines.

I'm also slightly confused when you write "collect them". All the files
are currently "collected" in a single subdirectory, so what do you mean
by that? You are not talking about sharing the temp files between
different uses, are you? That creates a number of security concerns,
which is the reason the user name was added to the temp directory name
in the first place. The whole concept of a shared /tmp directory is
somewhat of a security nightmare.

So what is the advantage of putting the temp files into a different
directory?

>  I see a multitude of possibilities here - allow me to define --tmpdir
>  so that it will automatically creates it before using it (with some
>  chmod value...). Combine this with making it overridable by an envvar
>  defined by me. Possibly, it would also need some way of downgrading to
>  the current defaults if nothing else applies.

--tmpdir really only exists as an escape for people who deploy
applications to environments where they have no write access to /tmp and
can't set environment variables either (limited web hosting accounts).

>  Yes - this opens some questions and would need some trashing to get
>  right. Further, it should obviously not break anything that uses --
>  tmpdir today. My thought would be to equip the --tmpdir with something
>  similar to --bind for the extra features I'd like to see.

I think I don't really understand the real problem yet, and how any
supposed change would actually solve this problem.

Cheers,
-Jan


_______________________________________________
PDK mailing list
PDK@[...].com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs