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/
>>
>
Received on 2007-02-13Z17:03:10