What's the perfect (OS independent) way of storing filepaths ?

[Lawrence D'Oliveiro]

Re: What's the perfect (OS independent) way of storing filepaths ?

In message <gdlsr7$n59$1@r umours.uwaterlo o.ca>, Ross Ridge wrote:

Ross Ridge wrote:
>

>As opposed to the file system being the single point failure?

>
Lawrence D'Oliveiro <ldo@geek-central.gen.new _zealandwrote:

>>The file system is involved regardless. But leaving out an additional
>>layer of failure on top of it does make things more robust, yes.

>
No, that doesn't follow. Having TCP as layer on top of IP doesn't make
the Internet less robust even though it's additional point of failure.

Which is a vacuous example.

For the matter, settings files also have an additional layer of failure
in the code that intreprets and updates the setting files.

See, it's clear you're too accustomed to the Windows mentality:
under "settings files" you're subsuming system config files, read-only
shared data, writeable data and per-user prefs--a whole bunch of things.
Recognize the distinction between these, and the fact that they need to be
kept distinct, and you can see how your assertions no longer hold up.

>>The file system already has provisions for simultaneous access by multiple
>>processes, journalling, integrity checking etc; implementing a "registry"
>>on top of this means reinventing a whole separate API and architecture
>>that has to provide this sort of thing, or leave it out and suffer the
>>well-known consequences.

>
If settings files benefit from those provisions of the filesystem then
so does the registry. If the registry needs additional provisions so
do settings files for the same reasons.

Quite different reasons, as I pointed out above.

>>Plus the fact that the Windows Registry is actually a munging together of
>>things that are kept in quite separate places in Unix/Linux: system config
>>files versus shared read-only data versus writable data versus user prefs
>>etc. Putting all these things together just makes it more likely that
>>somebody will clobber something it didn't mean to.

>
Nope. Microsoft implemented the registry because users were clobbering
things they weren't ment to, and it succeded in making it a less likely
occurence.

<http://www.google.co.n z/search?q=regist ry+damage+prone >

[Steven D'Aprano]

Re: What's the perfect (OS independent) way of storing filepaths ?

On Tue, 21 Oct 2008 10:00:35 -0500, Grant Edwards wrote:

>It is true that all kinds of programs will create .app files in your
>home dir which is not very polite.

>
It _is_ polite. Polite means following the established rules and doing
what's expected of you. That's exactly what is expected of applications
under Unix.

In medieval Russia, the Rus vikings (from whom modern Russia gets its
name) used to live in communal log huts. In the morning, a slave would
bring along a great big steaming bowl of water for the Rus to wash their
faces in. *One* bowl. The first person would wash his face, blow his nose
and spit in the bowl, then pass it on to the next person, who would
repeat all down the line.

This was the established social rules and everybody did what was expected
of them. It was also as rude as hell, and not just because "rude" also
means "unpolished , uncultured".

Putting preferences files in the user's top level directory is horribly
inconvenient for the user. It clutters their home directory. The old-time
Unix people recognised this, and made the files hidden so that their mess
wasn't visible. It certainly wasn't to protect the user from themselves,
because their users were other old-time Unix geeks who not only were
comfortable editing config files but expected to be able to. No, the only
reason for hiding the config files was because otherwise the user's home
directory would be too messy.

But of course all that means is that you avoid the mess so long as you
don't look at it. I have 125 dot files in my home directory. They include
"temporary" files from programs I haven't run in months, settings from
applications I haven't even heard of (where the hell did
".parallelreali ties" come from?), log files, lock files and other dross
that has no place scattered across my home directory. Half of these files
contain important data which users will invariably miss when making
backups, and half of them are junk that don't need to be copied when
making backups (e.g. .thumbnails, .Trash), but there's no easy way to
include some while excluding others.

It may be expected, but it is still inconsiderate and just plain
*stupid*. A thirty year old stupidity is still a stupidity.

It would have been easy to avoid this: just copy the relevant bits of
the / directory hierarchy in the user's home directory. Global settings
go in /etc and per user settings go in ~/etc. Global temp files go into /
tmp and per user temp files go into ~/tmp. And so forth. Nice, neat and
perfectly easy to implement and easy to deal with.



--
Steven

[Joe Strout]

Re: What's the perfect (OS independent) way of storing filepaths ?

On Oct 22, 2008, at 10:00 PM, Steven D'Aprano wrote:

It would have been easy to avoid this: just copy the relevant bits of
the / directory hierarchy in the user's home directory. Global
settings
go in /etc and per user settings go in ~/etc. Global temp files go
into /
tmp and per user temp files go into ~/tmp. And so forth. Nice, neat
and
perfectly easy to implement and easy to deal with.

I agree with you wholeheartedly on this one.

FYI, I think what you're looking for is a Mac. It's a Unix system,
and has /etc, but that's pretty much only there for compatibility with
other Unices -- well-behaved Mac apps put global settings (and so on)
in the appropriate subfolder under /Library, with per user data in the
appropriate subfolder under ~/Library.

Cheers,
- Joe

[Robert Brown]

Re: What's the perfect (OS independent) way of storing filepaths ?

Stef Mientki <stef.mientki@g mail.comwrites:

I (again) wonder what's the perfect way to store, OS-independent, filepaths ?
I can think of something like:
- use a relative path if drive is identical to the application (I'm still a
Windows guy)
- use some kind of OS-dependent translation table if on another drive
- use ? if on a network drive

There is no perfect solution, since file names and semantics differ from one
operating system to the next. Genera, the Lisp Machine operating system, has
facilities to abstract over the details of the file systems in use in the
1980s: Multics, ITS, TOPS-20, VMS, Unix, etc. Many of the concepts were
incorporated into the Common Lisp standard. Here are a couple of references:

http://gigamonkeys.com/book/files-and-file-io.html#filenames

http://www.lispworks.com/documentation/HyperSpec/Body/19_.htm

The system described is not simple. Briefly, there's a machine-independent
way (logical pathnames) to specify file names that a program can use to
manipulate the files it knows about. There's no guarantee that you can access
an arbitrary file with these names. However, there's also the concept of a
machine-specific file namestring. Users can type in these machine-specific
namestrings, allowing the code to access arbitrary files.

Both types of pathnames can be manipulated via an API to derive other file
names. Here's how I create a pathname that refers to a subdirectory of my
home directory:

(merge-pathnames
(make-pathname :directory '(:relative ".sbcl" "systems"))
(user-homedir-pathname))

The code should work so long as the target file system supports
subdirectories, as Windows and Unix do.

bob

[Lawrence D'Oliveiro]

Re: What's the perfect (OS independent) way of storing filepaths ?

In message <010fefe5$0$206 57$c3e8da3@news .astraweb.com>, Steven D'Aprano
wrote:

Putting preferences files in the user's top level directory is horribly
inconvenient for the user.

There is a way around this: redefine the HOME environment variable to be the
directory where you want the dotfiles to end up.

[Paul McNett]

Re: What's the perfect (OS independent) way of storing filepaths?

Steven D'Aprano wrote:

On Sun, 19 Oct 2008 20:50:46 +0200, Stef Mientki wrote:
>

>Duncan, in windows it's begin to become less common to store settings in
>Docs&Setting s,
>because these directories are destroyed by roaming profiles

The directories aren't destroyed by roaming profiles. When the user logs
out, they get copied to the server. When they log in at a different
machine, they get copied to the workstation.

So configuration information saved in c:\Documents and
Settings\pmcnet t\Application Data\My Application gets conveniently
migrated from machine to machine where I happen to login.

A really nice feature.

Isn't *everything* destroyed by roaming profiles? *wink*

I've heard such bashing of roaming profiles but I've never had anything
but love for them. That is, until people go and start saving their
movies and pictures in My Documents. Which is why I set their home
directory to a server share and have them save their docs there.

Seriously, I don't know anyone who has anything nice to say about roaming
profiles.

I loathe Windows, but roaming profiles was one thing they did (mostly)
right. I couldn't be happy in a world that didn't include roaming profiles.

Perhaps I'm not seeing the worst of it as I use Samba on Linux as the PDC?

Anyway, on Windows user configuration information should go in the
user's Application Data directory. If you don't want it to roam, you can
instead put it in the (hidden) Local Settings/Application Data directory.

Paul