Ada.Directories

Ada.Directories

[Dmitry A. Kazakov]

Hi all,

I have noticed that GNAT implementation of Ada.Directories.Search "finds"
the directory being searched and its immediate ancestor in itself (under
the names "." and ".."). Is it a bug or "feature"? If latter, then I would
expect at least a special File_Kind value reserved for the mess.

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

Re: Ada.Directories

[anon]

Its a "File System" feature!

In today's file systems, the first two entries are "." and ".." directories.  
One exception to this rule is the FAT file systems which does not contain 
these two entries.

So if you seach the entire directory, the first two names that will be 
returned are "." and ".." unless you search a FAT partition or a floopy.

All languages including Ada, C, JAVA that have directory search routine 
will act in same way.


In <qa32dfmc7uk9$.cb3cqu018xtz$.dlg@40tude.net>, "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>Hi all,
>
>I have noticed that GNAT implementation of Ada.Directories.Search "finds"
>the directory being searched and its immediate ancestor in itself (under
>the names "." and ".."). Is it a bug or "feature"? If latter, then I would
>expect at least a special File_Kind value reserved for the mess.
>
>-- 
>Regards,
>Dmitry A. Kazakov
>http://www.dmitry-kazakov.de

Re: Ada.Directories

[Dmitry A. Kazakov]

On Sat, 20 Oct 2007 18:43:21 GMT, anon wrote:

> Its a "File System" feature!
> 
> In today's file systems, the first two entries are "." and ".." directories.  
> One exception to this rule is the FAT file systems which does not contain 
> these two entries.

Neither the root directory of a volume does. But that is irrelevant to the
issue.

> So if you seach the entire directory, the first two names that will be 
> returned are "." and ".." unless you search a FAT partition or a floopy.
> 
> All languages including Ada, C, JAVA that have directory search routine 
> will act in same way.

I don't care how an OS-specific search might work. That is actually the
reason why I use Ada.Directories, which abstracts any concrete OS. So the
question is whether appearance of ".." is a requirement. Maybe, ".." is an
alias name? But then

1. Why there is no File_Kind value for aliases?

2. Why Full_Name of the Directory_Entry corresponding to ".." does not
render the true name of? Can the same file have different full names?

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

Re: Ada.Directories

[Maciej Sobczak]

On 20 Pa , 21:40, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> 2. Why Full_Name of the Directory_Entry corresponding to ".." does not
> render the true name of? Can the same file have different full names?

Of course. They are usually called "links". Add "mount points" and the
game is even more funny.
In general, there is no such a thing as a "true name" of a file and if
there are many there is often no way to assign different priorities
for them.
It's a feature. Most of the time.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Ada.Directories

[Dmitry A. Kazakov]

On Sat, 20 Oct 2007 13:35:25 -0700, Maciej Sobczak wrote:

> On 20 Pa , 21:40, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> 2. Why Full_Name of the Directory_Entry corresponding to ".." does not
>> render the true name of? Can the same file have different full names?
>
> Of course. They are usually called "links".

"." is not a hard/soft link, as it cannot be removed. Soft links are all
determinable. Even with hard links any file system is ADG, with ". " it is
not.

> Add "mount points" and the
> game is even more funny.

These are determinable as well.

> In general, there is no such a thing as a "true name" of a file and if
> there are many there is often no way to assign different priorities
> for them.

See RM A.16 which for Containing_Directory explicitly rules that if the
file system is not a forest, then Containing_Directory still returns a
value. That in effect defines a canonic full path for any Directory_Entry.
RM also does not hesitate to order that full names of abbreviations should
be meaningful.

So I think it also should advise implementations to remove "." and ".."
mess, when possible. At least in order to honor:

Compose (Containing_Directory (X), Simple_Name (X)) = X

(It makes no sense to define Containing_Directory without keeping the file
system view forest.)

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

Re: Ada.Directories

[Jacob Sparre Andersen]

Dmitry A. Kazakov wrote:

> "." is not a hard/soft link,

On a Unix system it _is_ a hard link.

Greetings,

Jacob
-- 
The backhoe is the natural predator of the fiber optic cable.

Re: Ada.Directories

[Dmitry A. Kazakov]

On Sun, 21 Oct 2007 15:05:57 +0200, Jacob Sparre Andersen wrote:

> Dmitry A. Kazakov wrote:
> 
>> "." is not a hard/soft link,
> 
> On a Unix system it _is_ a hard link.

AFAIK, no, because you cannot unlink it:

$ mkdir Test
$ ls -CFa Test
./ ../
$ <somehow unlink> Test/.
$ ls -CFa Test
../
$ <somehow unlink> Test/..
$ ls -CFa Test

Finally, as it should be from the very beginning! (:-))

[When links are reference counted, as IMO it is in Unix, then you obviously
cannot introduce cycles without ruining the file system.]

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

Re: Ada.Directories

[Markus E L]

"Dmitry A. Kazakov" wrote:

> On Sun, 21 Oct 2007 15:05:57 +0200, Jacob Sparre Andersen wrote:
>
>> Dmitry A. Kazakov wrote:
>> 
>>> "." is not a hard/soft link,
>> 
>> On a Unix system it _is_ a hard link.
>
> AFAIK, no, because you cannot unlink it:

Well, no Dmitry. It _is_ - as Jacob said - a hard link. One that
cannot be removed. Look at the link count for directories and learn
something. Why do you think it is 2+N where N is the number of
subdirectories in the directory? Think about ".." and ".".

Even when "." and ".." are not implemented as actual hard links in the
directory structure (like in AFAIR JFS) the FS code takes any effort
to maintain the illusion that there are hard links. This is part of
the interface contract (AFAIK even described in various standards).

> Finally, as it should be from the very beginning! (:-))
>
> [When links are reference counted, as IMO it is in Unix, then you obviously
> cannot introduce cycles without ruining the file system.]

Certainly. That is why hardlinking directories is forbidden for the
users.

Please don't start on of your discussions on definitions now. For once
I have noticed earlier that your Unix know-how is somehow a bit
lacking and on the other side you can go against what's written in
literature (just look at a number of books on OS design and
implementation) if you like, but that will be hardly convincing.

Regards -- Markus

PS: Another thing for you to think about:

    tmp/:$ ls -id t
    130716 t
    tmp/:$ ls -id t/.
    130716 t/.
    
    tmp/:$ ls -id t/u
    130718 t/u
    tmp/:$ ls -id t/u/.
    130718 t/u/.
    tmp/:$ ls -id t/u/..
    130716 t/u/..

    Hm. See a pattern (the number is the inode number, see ls(1))?

Re: Ada.Directories

[Jacob Sparre Andersen]

Dmitry A. Kazakov wrote:
> On Sun, 21 Oct 2007 15:05:57 +0200, Jacob Sparre Andersen wrote:
>> Dmitry A. Kazakov wrote:

>>> "." is not a hard/soft link,
>> 
>> On a Unix system it _is_ a hard link.
>
> AFAIK, no, because you cannot unlink it:

Unfortunately what you know isn't quite right.

> $ mkdir Test
> $ ls -CFa Test
> ./ ../

If you had used the command "ls -la" at this point, you would have
seen something like this:

total 12
drwxr-xr-x  2 sparre sparre 4096 Oct 21 17:32 .
drwxrwxrwt 12 root   root   8192 Oct 21 17:34 ..

The important part here is the "2" in the second line.  It's the "link
count" for the file ".".  As you can see, there are two links to ".".
The one is "Test" in the parent directory, and the other is ".".

Greetings,

Jacob
-- 
"If you think Tuck has said something that is completely
 wrong, you are almost certainly missing something :-)"

Re: Ada.Directories

[Martin Krischik]

Dmitry A. Kazakov wrote:

> On Sun, 21 Oct 2007 15:05:57 +0200, Jacob Sparre Andersen wrote:
> 
>> Dmitry A. Kazakov wrote:
>> 
>>> "." is not a hard/soft link,
>> 
>> On a Unix system it is a hard link.
> 
> AFAIK, no, because you cannot unlink it:

That's because most Unix file systems won't allow hard links to directories
to be *manually* created and therefore also disallow them to be *manually*
deleted.

But a ban on manual creation and deletion won't mean they could not be
created automatically or implicitly.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada.Directories

[Dmitry A. Kazakov]

On Sun, 21 Oct 2007 19:19:21 +0200, Martin Krischik wrote:

> Dmitry A. Kazakov wrote:
> 
>> On Sun, 21 Oct 2007 15:05:57 +0200, Jacob Sparre Andersen wrote:
>> 
>>> Dmitry A. Kazakov wrote:
>>> 
>>>> "." is not a hard/soft link,
>>> 
>>> On a Unix system it is a hard link.
>> 
>> AFAIK, no, because you cannot unlink it:
> 
> That's because most Unix file systems won't allow hard links to directories
> to be *manually* created and therefore also disallow them to be *manually*
> deleted.
> 
> But a ban on manual creation and deletion won't mean they could not be
> created automatically or implicitly.

Show me *whatever* way to delete any of the references without deletion of
another.

But what about Ada.Directories?

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

Re: Ada.Directories

[Markus E L]

"Dmitry A. Kazakov" wrote:

> On Sun, 21 Oct 2007 19:19:21 +0200, Martin Krischik wrote:
>
>> Dmitry A. Kazakov wrote:
>> 
>>> On Sun, 21 Oct 2007 15:05:57 +0200, Jacob Sparre Andersen wrote:
>>> 
>>>> Dmitry A. Kazakov wrote:
>>>> 
>>>>> "." is not a hard/soft link,
>>>> 
>>>> On a Unix system it is a hard link.
>>> 
>>> AFAIK, no, because you cannot unlink it:
>> 
>> That's because most Unix file systems won't allow hard links to directories
>> to be *manually* created and therefore also disallow them to be *manually*
>> deleted.
>> 
>> But a ban on manual creation and deletion won't mean they could not be
>> created automatically or implicitly.
>
> Show me *whatever* way to delete any of the references without deletion of
> another.

When you show me a definition that this is a necessary criterion for
s.th. being a hard link. Again: Meditate about 'ls -i' and apply to
directories.

- M

Re: Ada.Directories

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> So I think it also should advise implementations to remove "." and ".."
> mess, when possible.

I think it makes sense for directory searches to ignore "." and ".."  on
Unix-like systems.  Nothing can be 100% portable in this area, but this
change would make things more portable.  Perhaps you should send a
comment to that effect to ada-comment@ada-auth.org.

- Bob

Re: Ada.Directories

[Harald Korneliussen]

On Oct 21, 9:40 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> "." is not a hard/soft link, as it cannot be removed.

When did removability become part of the definition of "hard link"?

Re: Ada.Directories

[Markus E L]

Harald Korneliussen wrote:

> On Oct 21, 9:40 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> "." is not a hard/soft link, as it cannot be removed.
>
> When did removability become part of the definition of "hard link"?

Never it did. This is just what happens to definitions that come into
contact with Dmitry. I've purposely waited seom time (well, even three
weeks) to write this answer. From the fact that Dmitry did not answer
any more one can usually see that he got the point. At least that's my
observation.

- M

Re: Ada.Directories

[Dmitry A. Kazakov]

On Thu, 15 Nov 2007 12:44:53 +0100, Markus E L wrote:

> Harald Korneliussen wrote:
> 
>> On Oct 21, 9:40 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>> wrote:
>>> "." is not a hard/soft link, as it cannot be removed.
>>
>> When did removability become part of the definition of "hard link"?
> 
> Never it did. This is just what happens to definitions that come into
> contact with Dmitry. I've purposely waited seom time (well, even three
> weeks) to write this answer. From the fact that Dmitry did not answer
> any more one can usually see that he got the point. At least that's my
> observation.

No, I still haven't got it. But because we don't have a workable definition
of hard link, it just makes no sense to me to discuss it. And even if we
had, it were totally irrelevant to the issue of Ada.Directories.

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

Re: Ada.Directories

[Martin Krischik]

Dmitry A. Kazakov wrote:

> On Thu, 15 Nov 2007 12:44:53 +0100, Markus E L wrote:
> 
>> Harald Korneliussen wrote:
>> 
>>> On Oct 21, 9:40 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>>> wrote:
>>>> "." is not a hard/soft link, as it cannot be removed.
>>>
>>> When did removability become part of the definition of "hard link"?
>> 
>> Never it did. This is just what happens to definitions that come into
>> contact with Dmitry. I've purposely waited seom time (well, even three
>> weeks) to write this answer. From the fact that Dmitry did not answer
>> any more one can usually see that he got the point. At least that's my
>> observation.
> 
> No, I still haven't got it. But because we don't have a workable 
> definition of hard link, it just makes no sense to me to discuss it. And
> even if we had, it were totally irrelevant to the issue of
> Ada.Directories.

Sure we have. Each file is linked at least once and deleted if not.

I thought the discussion if about when a user is allowed to link / unlink
what kind of file.

And that is simple - you are not allowed to link or unlink directories. rm
is a high level command - try the low level "unlink" command and you will
see that it won't unlink any directory. And on the other hand ln won't
create links for directories. At least not on any unix I have come across.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada.Directories

[Larry Kilgallen]

In article <1589560.JmWJu6PyXJ@linux1.krischik.com>, Martin Krischik <krischik@users.sourceforge.net> writes:
> Dmitry A. Kazakov wrote:

>> No, I still haven't got it. But because we don't have a workable 
>> definition of hard link, it just makes no sense to me to discuss it. And
>> even if we had, it were totally irrelevant to the issue of
>> Ada.Directories.
> 
> Sure we have. Each file is linked at least once and deleted if not.
> 
> I thought the discussion if about when a user is allowed to link / unlink
> what kind of file.
> 
> And that is simple - you are not allowed to link or unlink directories. rm
> is a high level command - try the low level "unlink" command and you will
> see that it won't unlink any directory. And on the other hand ln won't
> create links for directories. At least not on any unix I have come across.

But the title of this topic is not restricted to Unix.

On VMS you can certainly apply SET FILE/ENTER and SET FILE/REMOVE to
a directory.

Re: Ada.Directories

[Martin Krischik]

Larry Kilgallen wrote:

> In article <1589560.JmWJu6PyXJ@linux1.krischik.com>, Martin Krischik
> <krischik@users.sourceforge.net> writes:
>> Dmitry A. Kazakov wrote:
> 
>>> No, I still haven't got it. But because we don't have a workable
>>> definition of hard link, it just makes no sense to me to discuss it. And
>>> even if we had, it were totally irrelevant to the issue of
>>> Ada.Directories.
>> 
>> Sure we have. Each file is linked at least once and deleted if not.
>> 
>> I thought the discussion if about when a user is allowed to link / unlink
>> what kind of file.
>> 
>> And that is simple - you are not allowed to link or unlink directories.
>> rm is a high level command - try the low level "unlink" command and you
>> will see that it won't unlink any directory. And on the other hand ln
>> won't create links for directories. At least not on any unix I have come
>> across.
> 
> But the title of this topic is not restricted to Unix.
> 
> On VMS you can certainly apply SET FILE/ENTER and SET FILE/REMOVE to
> a directory.

Indeed - but then VMS does not have that silly "." and ".." in any
directory. Also GNU ln has:


  -d, -F, --directory          dem Super-User den Versuch erlauben, harte
                                 Verknï¿œpfungen fï¿œr Verzeichnisse anzulegen
                                 (Bem.: Schlï¿œgt vermutlich dennoch fehl
wegen
                                 Systembeschrï¿œnkungen, auch fï¿œr Super-User.)

Sorry, try again:

 -d, -F, --directory         allow the superuser to attempt to hard link
                                directories (note: will probably fail due to
                                system restrictions, even for the superuser)

but I have never found a unix where it worked.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada.Directories

[Dmitry A. Kazakov]

On Fri, 16 Nov 2007 17:48:55 +0100, Martin Krischik wrote:

> Dmitry A. Kazakov wrote:
> 
>> On Thu, 15 Nov 2007 12:44:53 +0100, Markus E L wrote:
>> 
>>> Harald Korneliussen wrote:
>>> 
>>>> On Oct 21, 9:40 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>>>> wrote:
>>>>> "." is not a hard/soft link, as it cannot be removed.
>>>>
>>>> When did removability become part of the definition of "hard link"?
>>> 
>>> Never it did. This is just what happens to definitions that come into
>>> contact with Dmitry. I've purposely waited seom time (well, even three
>>> weeks) to write this answer. From the fact that Dmitry did not answer
>>> any more one can usually see that he got the point. At least that's my
>>> observation.
>> 
>> No, I still haven't got it. But because we don't have a workable 
>> definition of hard link, it just makes no sense to me to discuss it. And
>> even if we had, it were totally irrelevant to the issue of
>> Ada.Directories.
> 
> Sure we have. Each file is linked at least once and deleted if not.
> 
> I thought the discussion if about when a user is allowed to link / unlink
> what kind of file.

You may not be allowed to remove a link, but that is irrelevant. Access
rights is not a property of link. They are of "owned object."

The question is whether a proper link can be semantically removed. It can.

(I hope that you can erase your street address from the address book even
if the latter lies at your home, as well as that houses without address
books hidden in do not collapse... (:-))

If you want the reason why "." cannot be semantically removed, then it is
because the structure of links is broken (self-recursive). Therefore it
requires special handling, like synchronous deletion/insertion of cycles.

I wonder why this need to be so hotly discussed in c.l.a? Let it be the
most linked link of the world, if that helped us to return back to Ada
discussions...

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

Re: Ada.Directories

[anon]

The "." and ".." are not aliases they are actual directory entries in each 
directory, except for FAT partitions. 

Note: Any directory can have sub-directories with the same name that 
exist in other directories or sub-directories. Just that in this case the 
"." and ".." each have specific value set by the file system drivers 
under the operating system.

Like:

  / (root) => 
      .  -- point to / aka root
      .. -- point to / aka root ( special case )

      sub-dir_0 => 
          .  -- point to /sub-dir_0
          .. -- point to / aka root

          sub-dir_2 => 
              .  -- point to /sub-dir_0/sub-dir_2
              .. -- point to /sub-dir_0

    ...

Now in using the Directory_Search ( "/Sub_Dir_0/Sub_Dir_2_0/*" ) 

First entry would be a record that contain the Entry_ID "." and 
a allocation_link of "/Sub_Dir_0/Sub_Dir_2_0

Second entry would be a record that contain the Entry_ID ".." and 
a allocation_link will be "/Sub_Dir_0

The file system designer and OS designer even though you do not like 
it, created a standard that uses "." to mean current directory and ".." 
to represent the current directory parent directory. This has nothing to 
do with GNAT or Ada. The file system standards have been adopted 
by the "Ada Standards" for Ada 2005. In general, that means that 
Ada.Directory and its sub packages link to the OS user routines and 
insert the data into a Directory Record that is in the "Ada Standards".  
Which means you are dealing with specfic details of the OS file system 
that can be use in any language.

Also, there is no direct way to render the "." or ".." to its name true 
name, in any language.  You must build a routine that first compares 
the allocation of "." and "..", if equal then current directory is root. 
Else the routine searches the parent directory ("..") for the same 
allocation as the current directory (".").  Once found then the name_id 
is the current directory name. 


In <1o4hp0vtlenw0.jql7yewhhr4a.dlg@40tude.net>, "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>On Sat, 20 Oct 2007 18:43:21 GMT, anon wrote:
>
>> Its a "File System" feature!
>> 
>> In today's file systems, the first two entries are "." and ".." directories.  
>> One exception to this rule is the FAT file systems which does not contain 
>> these two entries.
>
>Neither the root directory of a volume does. But that is irrelevant to the
>issue.
>
>> So if you seach the entire directory, the first two names that will be 
>> returned are "." and ".." unless you search a FAT partition or a floopy.
>> 
>> All languages including Ada, C, JAVA that have directory search routine 
>> will act in same way.
>
>I don't care how an OS-specific search might work. That is actually the
>reason why I use Ada.Directories, which abstracts any concrete OS. So the
>question is whether appearance of ".." is a requirement. Maybe, ".." is an
>alias name? But then
>
>1. Why there is no File_Kind value for aliases?
>
>2. Why Full_Name of the Directory_Entry corresponding to ".." does not
>render the true name of? Can the same file have different full names?
>
>-- 
>Regards,
>Dmitry A. Kazakov
>http://www.dmitry-kazakov.de

Re: Ada.Directories

[Larry Kilgallen]

In article <d%rSi.245768$ax1.158475@bgtnsc05-news.ops.worldnet.att.net>, anon@anon.org (anon) writes:
> Its a "File System" feature!
> 
> In today's file systems, the first two entries are "." and ".." directories.  
> One exception to this rule is the FAT file systems which does not contain 
> these two entries.

Another is directories on VMS, for which there is a supported GNAT version.

> So if you seach the entire directory, the first two names that will be 
> returned are "." and ".." unless you search a FAT partition or a floopy.
> 
> All languages including Ada, C, JAVA that have directory search routine 
> will act in same way.

Re: Ada.Directories

[Adam Beneschan]

On Oct 20, 2:21 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> Hi all,
>
> I have noticed that GNAT implementation of Ada.Directories.Search "finds"
> the directory being searched and its immediate ancestor in itself (under
> the names "." and ".."). Is it a bug or "feature"? If latter, then I would
> expect at least a special File_Kind value reserved for the mess.

This isn't an easy question.  However, I'd say that it's probably
right to treat "." and ".." as nothing special (at least on Unix-type
system), since that's what I think users expect; they expect to be
able to use "." and ".." as if they were ordinary subdirectory names.
I could be wrong about that.

The flip side is that A.16(45) defines a "directory" as a "container
for files on the target system", and it seems odd to have a directory
containing itself, or its ancestor.  I still think of directory
structures as tree structures, but allowing a directory to contain
itself or its parent makes the structure seem a bit more like a Klein
bottle than a tree.  But since directories on Unix already can contain
references to other directories in other parts of the tree (e.g. hard
links and symbolic links), the structure already isn't a really tree
structure, so I don't see a particular problem with allowing a
directory to contain references to itself and to its parent.  The
"directory" definition has to be somewhat loose anyway, since this
package has to be usable on multiple operating systems.

Maybe the GNAT folks can add a subpackage of Ada.Directories that
contains a routine to control whether "." and ".." are seen as part of
a "directory" file or are treated as invisible.  It seems to me that
it might be appreciated by other users besides Dmitry.  If I used the
Ada.Directories.Search function, I'd probably appreciate the ability
to control this.

                        -- Adam

Re: Ada.Directories

[Peter Hermann]

Adam Beneschan <adam@irvine.com> wrote:
> Maybe the GNAT folks can add a subpackage of Ada.Directories that

maybe there exists some code for
standardized portable handling of path strings?

Re: Ada.Directories

[Larry Kilgallen]

In article <ffkdem$1oe$1@infosun2.rus.uni-stuttgart.de>, Peter Hermann <ica2ph@lucky.ihr.uni-stuttgart.de> writes:
> Adam Beneschan <adam@irvine.com> wrote:
>> Maybe the GNAT folks can add a subpackage of Ada.Directories that
> 
> maybe there exists some code for
> standardized portable handling of path strings?

I doubt it.  Handle this:

	SYS$SYSTEM:SECURITY.AUDIT$JOURNAL;-1

Typically SYS$SYSTEM is a logical name pointing to a rooted directory,
but there have been cases where particular customers have made it a
triple-rooted directory rather than single.  The only reliable way to
figure out what is going on is to call the appropriate VMS system servce.

Re: Ada.Directories

[Peter Hermann]

Larry Kilgallen <Kilgallen@spamcop.net> wrote:
> Peter Hermann writes:
> > Adam Beneschan <adam@irvine.com> wrote:
> >> Maybe the GNAT folks can add a subpackage of Ada.Directories that
> > 
> > maybe there exists some code for
> > standardized portable handling of path strings?
> 
> I doubt it.  Handle this:
> 
>         SYS$SYSTEM:SECURITY.AUDIT$JOURNAL;-1
> 
> Typically SYS$SYSTEM is a logical name pointing to a rooted directory,
> but there have been cases where particular customers have made it a
> triple-rooted directory rather than single.  The only reliable way to
> figure out what is going on is to call the appropriate VMS system servce.

i.e. reduction to
1. addressing device to be omitted?
2. file cycling to be omitted...
3. uniform identifier for home.
4. both '\' and '/' always accepted even mixed within path.

Re: Ada.Directories

[Robert A Duff]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> In article <ffkdem$1oe$1@infosun2.rus.uni-stuttgart.de>, Peter Hermann <ica2ph@lucky.ihr.uni-stuttgart.de> writes:
>> Adam Beneschan <adam@irvine.com> wrote:
>>> Maybe the GNAT folks can add a subpackage of Ada.Directories that
>> 
>> maybe there exists some code for
>> standardized portable handling of path strings?
>
> I doubt it.  Handle this:
>
> 	SYS$SYSTEM:SECURITY.AUDIT$JOURNAL;-1
>
> Typically SYS$SYSTEM is a logical name pointing to a rooted directory,
> but there have been cases where particular customers have made it a
> triple-rooted directory rather than single.  The only reliable way to
> figure out what is going on is to call the appropriate VMS system servce.

What's a triple-rooted directory?

Common Lisp has pretty good support for mostly-portable handling of path
names.  It includes support for VMS, if I remember correctly.

- Bob

Re: Ada.Directories

[Larry Kilgallen]

In article <wccejflhkz7.fsf@shell01.TheWorld.com>, Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> 
>> In article <ffkdem$1oe$1@infosun2.rus.uni-stuttgart.de>, Peter Hermann <ica2ph@lucky.ihr.uni-stuttgart.de> writes:
>>> Adam Beneschan <adam@irvine.com> wrote:
>>>> Maybe the GNAT folks can add a subpackage of Ada.Directories that
>>> 
>>> maybe there exists some code for
>>> standardized portable handling of path strings?
>>
>> I doubt it.  Handle this:
>>
>> 	SYS$SYSTEM:SECURITY.AUDIT$JOURNAL;-1
>>
>> Typically SYS$SYSTEM is a logical name pointing to a rooted directory,
>> but there have been cases where particular customers have made it a
>> triple-rooted directory rather than single.  The only reliable way to
>> figure out what is going on is to call the appropriate VMS system servce.
> 
> What's a triple-rooted directory?

I should have said "double" instead of "single" above, which would be:

$ show logical sys$sysroot
   "SYS$SYSROOT" = "DSA6:[SYS0.]" (LNM$SYSTEM_TABLE)
        = "SYS$COMMON:"
1  "SYS$COMMON" = "DSA6:[SYS0.SYSCOMMON.]" (LNM$SYSTEM_TABLE)

a triple rooted directory example is:

$ show logical DECW$SYSTEM_DEFAULTS
   "DECW$SYSTEM_DEFAULTS" = "SYS$LOGIN_DEVICE:[GREG.TOOLS.DECW]" (LNM$PROCESS_TABLE)
        = "SYS$COMMON:[DECW$DEFAULTS.USER]"
        = "SYS$COMMON:[DECW$DEFAULTS.SYSTEM]"
        = "SYS$LIBRARY:"
1  "SYS$LIBRARY" = "SYS$SYSROOT:[SYSLIB]" (LNM$SYSTEM_TABLE)
   "DECW$SYSTEM_DEFAULTS" = "SYS$SYSROOT:[DECW$DEFAULTS.USER]" (DECW$LOGICAL_NAMES)
        = "SYS$SYSROOT:[DECW$DEFAULTS.SYSTEM]"
        = "SYS$LIBRARY:"
1  "SYS$LIBRARY" = "SYS$SYSROOT:[SYSLIB]" (LNM$SYSTEM_TABLE)
$

> Common Lisp has pretty good support for mostly-portable handling of path
> names.  It includes support for VMS, if I remember correctly.

Certainly that is possible, but it involves OS-specific code not
implied by sentence that prompted my comment.

>>> maybe there exists some code for
>>> standardized portable handling of path strings?

Re: Ada.Directories

[Brian May]

>>>>> "Adam" == Adam Beneschan <adam@irvine.com> writes:

    Adam> This isn't an easy question.  However, I'd say that it's
    Adam> probably right to treat "." and ".." as nothing special (at
    Adam> least on Unix-type system), since that's what I think users
    Adam> expect; they expect to be able to use "." and ".." as if
    Adam> they were ordinary subdirectory names.  I could be wrong
    Adam> about that.

The fact is they are special, normally you can't have a hard link to a
directory, and as such you normally can't create loops in the
directory structure.

As for this issue, I would be happy if the behaviour was to alway
return "." and ".." or never return "." and ".." regardless of file
system. i.e. the application gets the same results all the time, and
doesn't have to have code that is specific to a filesystem (and might
break if suddenly used on another filesystem).

Perhaps the later might be more useful though, when listing
directories I almost never care about "." and ".." and would have to
filter them out anyway.
-- 
Brian May <bam@snoopy.apana.org.au>