Re: Ada.Directories problems, a summary

[Georg Bauhaus <rm.tsoh.plus-bug.bauhaus@maps.futureapps.de>]

Dmitry A. Kazakov wrote:
> After experimenting with Ada.Directories I collected the issues I think
> must be addressed to make Ada.Directories more usable:
> 
> 1. Name encoding. Either String versions should be UTF-8 or else replaced
> with Wide_Wide_String ones.

Just for clarification, do you want ISO 10646 names to be used
in Ada program texts so that Ada.Directories can map the Ada
string names to file system names? (The file system using whichever
encoding seems fit?)


> 2. Name canonization / comparison functions. Presently it is impossible to
> compare files by names because the same file may have potentially an
> infinite number of names.

I suppose this refers to paths, such as full names, and includes 1.?
(E.g., if the OSs do not make unique ids available to the computer
user (such as i-nodes) it is unlikely that an application program could.
Does Apple have copyright on iNode?)


> 4. There should be a variant of Start_Search without the Directory
> parameter, in order to enumerate the roots of the file systems. For
> example, to find drive letters under Windows, network shares, mount points
> etc.

OTOH, if you know where to start strolling along that file system
grove, you have virtually named a virtual root...

> 5. The behavior of Exists must be specified for the case of mountable
> volumes. Presently GNAT implementation pops a message box under Windows.
> This should be outlawed.

What about "dynamic" behavior? An NFS server going away during
the mount operation, ...
IOW, what is special of this "availability property" when compared
to others such as a file being removed from the file system
after the program has opened the file?


> 7. Version number in addition to Containing_Directory, Base_Name and
> Extension. (Files have version numbers under VMS)

Not widespread.  A Child package maybe, provided by implementations?