Finding where to store application data portably

[Tony Houghton]

I'm using pygame to write a game called Bombz which needs to save some
data in a directory associated with it. In Unix/Linux I'd probably use
"~/.bombz", in Windows something like
"C:\Documen ts And Settings\<user> \Applicacation Data\Bombz".

There are plenty of messages in the archives for this group about how to
find the correct location in Windows, but what about Mac OS? There I
don't know the correct location for this sort of thing at all. And there
are other, more obscure systems like RISC OS (it may not have pygame but
it definitely has python). Surely this is something that's crying out
for an official function in os or sys.

--
The address in the Reply-To is genuine and should not be edited.
See <http://www.realh.co.uk/contact.html> for more reliable contact
addresses.

[Tony Houghton]

In <iA************ ********@tornad o.tampabay.rr.c om>,
Ron Adam <rr*@ronadam.co m> wrote:

Tony Houghton wrote:

> This works on Win XP. Not sure if it will work on Linux.
>
> import os
>
> parent = os.path.split(o s.path.abspath( os.sys.argv[0]))[0]
> file = parent + os.sep + '.bombz'

Ooh, no, I don't want saved data to go in the installation directory. In
general that practice encourages people to run with Admin access, and
it's about time Windows users were discouraged from that.

Yes, it occurred to me you didn't want to do that after I posted.

Looks like maybe the correct place would be as you suggested, but maybe
doing it this way would be better.

import os
user = os.path.join( os.environ["USERPROFIL E"],
'Application Data',
'Bombz' )

I like that, it's nice and simple. It doesn't look like it's supported
on Win 9x though, but on 9x using the installation directory would be
acceptable.

--
The address in the Reply-To is genuine and should not be edited.
See <http://www.realh.co.uk/contact.html> for more reliable contact addresses.

[Steven D'Aprano]

On Thu, 22 Sep 2005 19:09:28 +0400, en.karpachov wrote:

There is an other way around: look at your home dir as if it is your
"settings" dir and don't clutter it with files other than application
config dot-files. Just make ~/files/, ~/bin/ ~/lib/ etc. for it.

Do you put everything into /etc (/etc/bin, /etc/var, /etc/usr, /etc/mnt,
and so forth)? If your home directory is for settings, why would you store
files and binaries inside your settings directory?

I understand the historical reasons for why ~/ is treated as a
structureless grab-bag of everything and anything. That made sense back in
the distant past when users used dumb terminals and they had perhaps half
a dozen dot files. But at the point your home directory has three times as
many dot files as regular files, the time has come to stop doing things
just because that's the way they have always been done.

--
Steven.

[Ron Adam]

Steven D'Aprano wrote:

On Thu, 22 Sep 2005 19:09:28 +0400, en.karpachov wrote:

There is an other way around: look at your home dir as if it is your
"settings" dir and don't clutter it with files other than application
config dot-files. Just make ~/files/, ~/bin/ ~/lib/ etc. for it.

Do you put everything into /etc (/etc/bin, /etc/var, /etc/usr, /etc/mnt,
and so forth)? If your home directory is for settings, why would you store
files and binaries inside your settings directory?

I understand the historical reasons for why ~/ is treated as a
structureless grab-bag of everything and anything. That made sense back in
the distant past when users used dumb terminals and they had perhaps half
a dozen dot files. But at the point your home directory has three times as
many dot files as regular files, the time has come to stop doing things
just because that's the way they have always been done.

Yes, it's all pretty much historical isn't it. Someones needs to start
form scratch I think as far as file storage systems go.

Personally I'd love a cross platform intelligent file storage device
that managed security and user accounts independent of the operating
system. (With it's own internal CPU and firmware.)

A few thoughts ...

It should be built on concepts of 'Responsibility ', 'Authority', and
'Delegation', So you could call it.. RADOS or RAD for short, or just
use my initials. RA.. (just kidding) ;-)

Also note that an application is just another user by proxy. And it all
comes down to private and shared user data. In other words, organize all
files by who's "Responsibl e" for them.

You would "Delegate Authority" by using file links with private keys in
them. Giving a file link to someone else wouldn't work since it would
need to be ran from your user account to be valid. These file links is
how you would access other files in other users file space.

Anyway... such a system would mean that when an application accesses the
Internet, (has Authority), to update it's own files, (Responsibility ),
it does so in it's own user space and can't access any other users (or
applications) files. Virus's would find this very limiting.

Every user account would be a complete unit which can be backed up and
restored independently of the OS. If something went wrong you could
always find out which user (or application developer) was responsible.

Anyway... just wishful thinking. I'm sure there are a lot of problems
that would need to be worked out. ;-)

Cheers,
Ron Adam