$HOME/.Nooooooo!

[John Taylor]

On 13 Feb 2007, at 15:35, Tony Linde wrote:

> Thanks for that, Mark.
>
>> use/abuse of a user's home directory is not much related to PLASTIC -
>
> No. that's why I started a new topic.


>
>> JVM (e.g. java -Djava.io.tmpdir=/disk/scratch) if required.
>> "java -Duser.home=/tmp/$USER -jar app.jar".
>
> Anyone know if it is possible to set these up in Webstart so  
> webstarted apps
> use the place?
>
> Wonder what java.io.tmpdir normally returns in Windows?

On my XP box it's C:\Docs and Settings\jdt\Local Settings\Temp

Tony - we need to distinguish between two different uses for writing  
out these files.  One is as a temporary scratch file used by a single  
application.  In this case it doesn't really matter where the file  
goes, and Java apps will typically put them in ${java.io.tmpdir} as  
Mark says.  On Windows this equates to a folder like the one give  
above, on Linux I guess it's probably /tmp.  It doesn't really matter  
where it is provided the user can write to it, there's enough space,  
and (ideally) the OS cleans it up once in a while.  The other case is  
that of a "well-known location".  The .plastic file used by PLASTIC  
isn't just used by the Plastic Hub, but by all plasticized  
applications.  So, it needs to be easily locatable on several  
different OS and in many different languages.  There aren't many good  
candidates for where it should be.   Most languages on the 3 main  
desktop OS seem to have a concept of the user's home directory, which  
is why we use it.  If we were to use ${java.io.tmpdir}, I wouldn't be  
confident that a Perl or Python program would necessarily be using  
the same temp folder.     On windows machines, there is the  
Environment.SpecialFolder.ApplicationData environment variable that  
seems to point to the folder you want us to use, but this isn't much  
use on other OSs.  I imagine that the apps you cite are able to use  
it as they are not platform independent - there's probably some OS- 
specific config going on at compile time.

John





>
> T.
>
>> -----Original Message-----
>> From: Mark Taylor [mailto:mbt at star.bris.ac.uk] On Behalf Of
>> Mark Taylor
>> Sent: 13 February 2007 15:24
>> To: Tony Linde
>> Subject: Re: $HOME/.Nooooooo!
>>
>> On Tue, 13 Feb 2007, Tony Linde wrote:
>>
>>> I'll raise this again as a separate topic.
>>>
>>> We're getting problems with (plastic) apps using .Xxxx
>> directories to store
>>> temporary files.
>>>
>>> Doing a demo the other day on a (WinXP) machine configured
>> by the department
>>> (and so not changeable) we kept getting 'profile storage
>> space exceeded'
>>> messages from the OS. This because all the apps were using
>> $HOME/.xxx
>>> directories as scratch space: this area in Windows is for
>> user profile
>>> information not general storage. We need some way that
>> users can point to
>>> some other 'home' directory for AR/PLASTIC apps.
>>>
>>> The main offender was Aladin because it stored a couple of
>> VOTable files in
>>> the $HOME/.aladin directory.
>>>
>>> Can I ask that anyone writing an application which might be
>> run under windows
>>> *not* store anything in the $HOME/.xxx type of directory.
>> Temporary files
>>> should go in the Temp directory and application profiles in a
>>> $HOME/Application Data/xxx directory.
>>>
>>> I see that gaim, firefox, thunderbird etc all do this
>> correctly - can someone
>>> look up how they handle it and place the advice up here?
>>
>> Tony and other interested parties,
>>
>> use/abuse of a user's home directory is not much related to PLASTIC -
>> as John said, there is a $HOME/.plastic file, but it's only a
>> couple of lines long.
>>
>> For java applications, the normal place to store temporary files
>> is in the directory given by the system property "java.io.tmpdir" -
>> this is typically /tmp on Unix, but may be set when invoking the
>> JVM (e.g. java -Djava.io.tmpdir=/disk/scratch) if required.
>>
>> If a java application is writing to a user's home directory
>> (and Aladin may have had its reasons for doing this) it is very  
>> likely
>> doing so by examining (directly or indirectly) the system property
>> "user.home".  You could change this behaviour by redefining that
>> system property when java is invoked, e.g.
>> "java -Duser.home=/tmp/$USER -jar app.jar".
>>
>> Non-java applications will mostly have OS-specific approaches to
>> these issues.
>>
>> Mark
>>
>> -- 
>> Mark Taylor   Astronomical Programmer   Physics, Bristol
>> University, UK
>> m.b.taylor at bris.ac.uk +44-117-928-8776
>> http://www.star.bris.ac.uk/~mbt/
>>
>