Re: Interpretation of extensions different from Unix/Linux?

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:t16bietxydy8$.10aq5n9g127pq$.dlg@40tude.net...
> On Fri, 21 Aug 2009 17:10:36 -0500, Randy Brukardt wrote:
...
>> These things have to come from
>> outside of the file system (commonly from the environment or GUI) and 
>> thus
>> Ada.Directories has nothing to do with their source.
>
> Huh, and what do the procedures Start_Search and Search there? All
> Ada.Directories is built around  them.

They're for finding out about the files/directories in a directory that you 
already know. Typically, a directory that your program created. The location 
of that directory should have come from some external source.

>> You want to use Ada.Directories for purposes for which it was not 
>> intended,
>
> That is certainly true. This is why I said that Ada.Directories is almost
> unusable. It cannot serve the purpose of searching a file system. The
> negligible rest is:
>
> 1. copy, delete files by name;
> 2. get modification time;
> 3. create directory;

You forgot:

4. search within a known directory.

And I don't consider any of these things "negligible". The Janus/Ada 
compiler depends heavily on the first two, and it is nice that we finally 
can get away from using non-portable kludges to get that information.

> 4. broken file name manipulation operations.

Of course they're broken! They were added over my objections; I don't think 
that it is possible to define useful file name manipulations that are also 
portable, implementable, well-defined, and consistent across 
implementations.

We tried anyway, and of course we got very limited results. And we'll try to 
extend them, and we'll still have operations of very limited use. If you 
need them perfect for a given OS, you *have* to write them yourself. And 
otherwise, maybe these are good enough, but don't expect perfection.

                                       Randy.