RE: pdk-SYSTEM-1080 files in windows

On Tue, 01 Feb 2005, Mathieu Longtin wrote:
> Looking at the description for --clean:>>   Clean up object files that were extracted from the application at>   runtime. By default, these files are cached in the temporary>   directory. This allows the next invocation of the app to start up>   faster.>> Since when is C:\windows a temporary directory?

It always has been Windows last resort if none of the environment
variables are set. Look at the GetTempPath() API:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/gettemppath.asp

> > Mathieu Longtin wrote:> >> > > I'm finding a whole bunch of of directories in my> > > c:\windows directory. They are all called something like> > >> > >   pdk-SYSTEM-1080 <--- the number changes

SYSTEM is the user name and 1080 is the process id. The reason it is
located in the Windows directory is that the application is running as
the SYSTEM user, which typically doesn't have a full user environment. I
assume you are running this from a service, or from the scheduler using
the SYSTEM account.

The temp directories ending with a process id should *always* be cleaned up.
The only time this doesn't happen is when the program ends without executing
the cleanup code.  This means either a crash, or something doing an abrupt
process exit, like calling POSIX::_exit().

> > > and they contain two DLLs that one of my perlapp project uses.> > >> > > Is there a way to ensure that those directories are removed?

The best course of action would be to figure out why the process exits
abnormally and then fix this situation.  If this is not possible, then
it may be better to *not* use the --clean option.  That way the files
should always be written to the same directory: pdk-SYSTEM and the
disk space usage at least stays constant.

Another option is to explore the --dyndll option introduced by PDK 6.0.
It only works on Windows NT and later, but it will not write any DLL to
the disk at all, so it would not leave the DLLS behind even if the
program aborts.

I still think that finding and fixing the cause of the abnormal
termination is the best way of proceeding.

Cheers,
-Jan