Re: Ada.Directories problems, a summary

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Fri, 02 Jan 2009 11:22:10 +0100, Georg Bauhaus wrote:

> 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?)

I mean, that you use Unicode names in the program and Ada RTL maps these
names onto the OS scheme.

If the file name contains code points unsupported by OS, you get
Name_Error, as expected. Implementation cost of this is about zero.

>> 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?)

It refers to the issues like:

1. Canonize ("d:/foo.txt") = "D:\Foo.txt"
    -- under Windows where names are case insensitive,
    -- but the case is stored. / is replaced with \ etc.

2. Canonize ("/a/../a/../a") = "/a"  -- removed indirections

>> 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...

Right. This is another way to achieve the same effect, by providing a
Directory_Entry_Type constant Root, which would be "/" under UNIX and
something virtual under other systems.

>> 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, ...

This is another issue. GTK for instance provides so-called monitors for
volumes, directories and files. This functionality is beyond
Ada.Directories, IMO.

The issue merely is that Exists must have no side effects beyond the its
result. It might raise Use_Error or Data_Error, but it may not pop up
messages, reboot the computer, send SMS etc.

> 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?

Nothing special, Exists returns False, end of story.

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

It is a more general model which implementation cost is almost zero (in its
simplest form).

Furthermore, think about source code management systems like ClearCase,
Subversion etc. These could be viewed as directory trees with nodes having
version numbers.

> A Child package maybe, provided by implementations?

Bad idea. That would make applications using it non-portable.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de