Re: [AD] Some more features for platform-independent file system?

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

On Tuesday 02 April 2002 23:18, Laurence Withers wrote:
>  - on DOS, the directory '/' doesn't refer to the root directory of the
>    current drive, but refers to a 'virtual' directory which has one
>    subdirectory for each valid drive. So, for a system with 2 dos
>    partitions and a CDROM, the root directory would look like:
>
>    /
>     c/        [refers to first dos partition]
>     d/        [refers to second dos partition]
>     e/        [refers to CDROM]
>
>    So to access c:\djgpp\file, you would use the name /c/djgpp/file .
>    Of course, the dos-style name will also be accepted.

I must say I don't really like this - what it does basically is transform 
the DOS/Windows filesystem to a UNIX like filesystem (which is a good 
thing in many ways), which IMHO is beyond the scope of a project such as 
Allegro.
Furthermore, it can break in a pretty bad way: say I have a directory (or 
even a file) called `c' in the root directory of my first drive, then how 
should `/c' be interpreted? As c:/ or as c:/c? The solution would be to 
use the /c/blahblah way to refer to partititions only, which is confusing 
for people used to the DOS way of doing this. DOS isn't UNIX, so don't 
pretend it is.
Also, I'm not quite sure what this would accomplish - it doesn't improve 
portability because /c, if it existed at all, wouldn't have the same 
meaning under UNIX as it would get under DOS.

>  - The directory ~/ is expanded to the user's home directory on
>    platforms where that concept exists, or the executable's actual
>    directory otherwise. This lets us store configuration files somewhere
>    sensible.

I like this idea. I currently use some platform dependent code to grab the 
$HOME variable under Linux.

>  - (Maybe) On dos systems, a preceding full stop on a file name is
>    skipped (so ~/.allegrorc would refer to that file on UNIX, but to
>    a file called 'allegrorc' (or truncation thereof) in the executable's
>    actual directory on dos). This lets us use sensible names for
>    config files on platforms which support it, but also handles dos
>    without any platform-specific code.

Though I don't have real solid objections to this, I'm not sure I like 
this one either. For one thing, with LFN enabled, .allegrorc is a 
perfectly valid name even under DOS. Secondly, calling the config file 
allegrorc under UNIX makes sense since that is the convention. It doesn't 
make sense under Windows, where the convention would be that it's called 
allegro.ini.

Evert