* Ada.Directories @ 2007-10-20 9:21 Dmitry A. Kazakov 2007-10-20 18:43 ` Ada.Directories anon 2007-10-22 18:56 ` Ada.Directories Adam Beneschan 0 siblings, 2 replies; 29+ messages in thread From: Dmitry A. Kazakov @ 2007-10-20 9:21 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-10-20 9:21 Ada.Directories Dmitry A. Kazakov @ 2007-10-20 18:43 ` anon 2007-10-20 19:40 ` Ada.Directories Dmitry A. Kazakov 2007-10-20 22:36 ` Ada.Directories Larry Kilgallen 2007-10-22 18:56 ` Ada.Directories Adam Beneschan 1 sibling, 2 replies; 29+ messages in thread From: anon @ 2007-10-20 18:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-10-20 18:43 ` Ada.Directories anon @ 2007-10-20 19:40 ` Dmitry A. Kazakov 2007-10-20 20:35 ` Ada.Directories Maciej Sobczak 2007-10-21 1:25 ` Ada.Directories anon 2007-10-20 22:36 ` Ada.Directories Larry Kilgallen 1 sibling, 2 replies; 29+ messages in thread From: Dmitry A. Kazakov @ 2007-10-20 19:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-10-20 19:40 ` Ada.Directories Dmitry A. Kazakov @ 2007-10-20 20:35 ` Maciej Sobczak 2007-10-21 7:40 ` Ada.Directories Dmitry A. Kazakov 2007-10-21 1:25 ` Ada.Directories anon 1 sibling, 1 reply; 29+ messages in thread From: Maciej Sobczak @ 2007-10-20 20:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-10-20 20:35 ` Ada.Directories Maciej Sobczak @ 2007-10-21 7:40 ` Dmitry A. Kazakov 2007-10-21 13:05 ` Ada.Directories Jacob Sparre Andersen ` (2 more replies) 0 siblings, 3 replies; 29+ messages in thread From: Dmitry A. Kazakov @ 2007-10-21 7:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-10-21 7:40 ` Ada.Directories Dmitry A. Kazakov @ 2007-10-21 13:05 ` Jacob Sparre Andersen 2007-10-21 13:26 ` Ada.Directories Dmitry A. Kazakov 2007-10-21 23:52 ` Ada.Directories Robert A Duff 2007-10-22 11:08 ` Ada.Directories Harald Korneliussen 2 siblings, 1 reply; 29+ messages in thread From: Jacob Sparre Andersen @ 2007-10-21 13:05 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-10-21 13:05 ` Ada.Directories Jacob Sparre Andersen @ 2007-10-21 13:26 ` Dmitry A. Kazakov 2007-10-21 15:29 ` Ada.Directories Markus E L ` (2 more replies) 0 siblings, 3 replies; 29+ messages in thread From: Dmitry A. Kazakov @ 2007-10-21 13:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-10-21 13:26 ` Ada.Directories Dmitry A. Kazakov @ 2007-10-21 15:29 ` Markus E L 2007-10-21 15:38 ` Ada.Directories Jacob Sparre Andersen 2007-10-21 17:19 ` Ada.Directories Martin Krischik 2 siblings, 0 replies; 29+ messages in thread From: Markus E L @ 2007-10-21 15:29 UTC (permalink / raw) "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))? ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-10-21 13:26 ` Ada.Directories Dmitry A. Kazakov 2007-10-21 15:29 ` Ada.Directories Markus E L @ 2007-10-21 15:38 ` Jacob Sparre Andersen 2007-10-21 17:19 ` Ada.Directories Martin Krischik 2 siblings, 0 replies; 29+ messages in thread From: Jacob Sparre Andersen @ 2007-10-21 15:38 UTC (permalink / raw) 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 :-)" ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-10-21 13:26 ` Ada.Directories Dmitry A. Kazakov 2007-10-21 15:29 ` Ada.Directories Markus E L 2007-10-21 15:38 ` Ada.Directories Jacob Sparre Andersen @ 2007-10-21 17:19 ` Martin Krischik 2007-10-21 18:52 ` Ada.Directories Dmitry A. Kazakov 2 siblings, 1 reply; 29+ messages in thread From: Martin Krischik @ 2007-10-21 17:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-10-21 17:19 ` Ada.Directories Martin Krischik @ 2007-10-21 18:52 ` Dmitry A. Kazakov 2007-10-21 20:32 ` Ada.Directories Markus E L 0 siblings, 1 reply; 29+ messages in thread From: Dmitry A. Kazakov @ 2007-10-21 18:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-10-21 18:52 ` Ada.Directories Dmitry A. Kazakov @ 2007-10-21 20:32 ` Markus E L 0 siblings, 0 replies; 29+ messages in thread From: Markus E L @ 2007-10-21 20:32 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-10-21 7:40 ` Ada.Directories Dmitry A. Kazakov 2007-10-21 13:05 ` Ada.Directories Jacob Sparre Andersen @ 2007-10-21 23:52 ` Robert A Duff 2007-10-22 11:08 ` Ada.Directories Harald Korneliussen 2 siblings, 0 replies; 29+ messages in thread From: Robert A Duff @ 2007-10-21 23:52 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-10-21 7:40 ` Ada.Directories Dmitry A. Kazakov 2007-10-21 13:05 ` Ada.Directories Jacob Sparre Andersen 2007-10-21 23:52 ` Ada.Directories Robert A Duff @ 2007-10-22 11:08 ` Harald Korneliussen 2007-11-15 11:44 ` Ada.Directories Markus E L 2 siblings, 1 reply; 29+ messages in thread From: Harald Korneliussen @ 2007-10-22 11:08 UTC (permalink / raw) 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"? ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-10-22 11:08 ` Ada.Directories Harald Korneliussen @ 2007-11-15 11:44 ` Markus E L 2007-11-16 13:27 ` Ada.Directories Dmitry A. Kazakov 0 siblings, 1 reply; 29+ messages in thread From: Markus E L @ 2007-11-15 11:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-11-15 11:44 ` Ada.Directories Markus E L @ 2007-11-16 13:27 ` Dmitry A. Kazakov 2007-11-16 16:48 ` Ada.Directories Martin Krischik 0 siblings, 1 reply; 29+ messages in thread From: Dmitry A. Kazakov @ 2007-11-16 13:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-11-16 13:27 ` Ada.Directories Dmitry A. Kazakov @ 2007-11-16 16:48 ` Martin Krischik 2007-11-16 18:47 ` Ada.Directories Larry Kilgallen 2007-11-16 19:00 ` Ada.Directories Dmitry A. Kazakov 0 siblings, 2 replies; 29+ messages in thread From: Martin Krischik @ 2007-11-16 16:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-11-16 16:48 ` Ada.Directories Martin Krischik @ 2007-11-16 18:47 ` Larry Kilgallen 2007-11-16 20:35 ` Ada.Directories Martin Krischik 2007-11-16 19:00 ` Ada.Directories Dmitry A. Kazakov 1 sibling, 1 reply; 29+ messages in thread From: Larry Kilgallen @ 2007-11-16 18:47 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-11-16 18:47 ` Ada.Directories Larry Kilgallen @ 2007-11-16 20:35 ` Martin Krischik 0 siblings, 0 replies; 29+ messages in thread From: Martin Krischik @ 2007-11-16 20:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-11-16 16:48 ` Ada.Directories Martin Krischik 2007-11-16 18:47 ` Ada.Directories Larry Kilgallen @ 2007-11-16 19:00 ` Dmitry A. Kazakov 1 sibling, 0 replies; 29+ messages in thread From: Dmitry A. Kazakov @ 2007-11-16 19:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-10-20 19:40 ` Ada.Directories Dmitry A. Kazakov 2007-10-20 20:35 ` Ada.Directories Maciej Sobczak @ 2007-10-21 1:25 ` anon 1 sibling, 0 replies; 29+ messages in thread From: anon @ 2007-10-21 1:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-10-20 18:43 ` Ada.Directories anon 2007-10-20 19:40 ` Ada.Directories Dmitry A. Kazakov @ 2007-10-20 22:36 ` Larry Kilgallen 1 sibling, 0 replies; 29+ messages in thread From: Larry Kilgallen @ 2007-10-20 22:36 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-10-20 9:21 Ada.Directories Dmitry A. Kazakov 2007-10-20 18:43 ` Ada.Directories anon @ 2007-10-22 18:56 ` Adam Beneschan 2007-10-23 9:04 ` Ada.Directories Peter Hermann 2007-10-24 0:55 ` Ada.Directories Brian May 1 sibling, 2 replies; 29+ messages in thread From: Adam Beneschan @ 2007-10-22 18:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-10-22 18:56 ` Ada.Directories Adam Beneschan @ 2007-10-23 9:04 ` Peter Hermann 2007-10-23 12:07 ` Ada.Directories Larry Kilgallen 2007-10-24 0:55 ` Ada.Directories Brian May 1 sibling, 1 reply; 29+ messages in thread From: Peter Hermann @ 2007-10-23 9:04 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-10-23 9:04 ` Ada.Directories Peter Hermann @ 2007-10-23 12:07 ` Larry Kilgallen 2007-10-23 13:01 ` Ada.Directories Peter Hermann 2007-10-23 16:08 ` Ada.Directories Robert A Duff 0 siblings, 2 replies; 29+ messages in thread From: Larry Kilgallen @ 2007-10-23 12:07 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-10-23 12:07 ` Ada.Directories Larry Kilgallen @ 2007-10-23 13:01 ` Peter Hermann 2007-10-23 16:08 ` Ada.Directories Robert A Duff 1 sibling, 0 replies; 29+ messages in thread From: Peter Hermann @ 2007-10-23 13:01 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-10-23 12:07 ` Ada.Directories Larry Kilgallen 2007-10-23 13:01 ` Ada.Directories Peter Hermann @ 2007-10-23 16:08 ` Robert A Duff 2007-10-23 17:11 ` Ada.Directories Larry Kilgallen 1 sibling, 1 reply; 29+ messages in thread From: Robert A Duff @ 2007-10-23 16:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-10-23 16:08 ` Ada.Directories Robert A Duff @ 2007-10-23 17:11 ` Larry Kilgallen 0 siblings, 0 replies; 29+ messages in thread From: Larry Kilgallen @ 2007-10-23 17:11 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Ada.Directories 2007-10-22 18:56 ` Ada.Directories Adam Beneschan 2007-10-23 9:04 ` Ada.Directories Peter Hermann @ 2007-10-24 0:55 ` Brian May 1 sibling, 0 replies; 29+ messages in thread From: Brian May @ 2007-10-24 0:55 UTC (permalink / raw) >>>>> "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> ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2007-11-16 20:35 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-10-20 9:21 Ada.Directories Dmitry A. Kazakov 2007-10-20 18:43 ` Ada.Directories anon 2007-10-20 19:40 ` Ada.Directories Dmitry A. Kazakov 2007-10-20 20:35 ` Ada.Directories Maciej Sobczak 2007-10-21 7:40 ` Ada.Directories Dmitry A. Kazakov 2007-10-21 13:05 ` Ada.Directories Jacob Sparre Andersen 2007-10-21 13:26 ` Ada.Directories Dmitry A. Kazakov 2007-10-21 15:29 ` Ada.Directories Markus E L 2007-10-21 15:38 ` Ada.Directories Jacob Sparre Andersen 2007-10-21 17:19 ` Ada.Directories Martin Krischik 2007-10-21 18:52 ` Ada.Directories Dmitry A. Kazakov 2007-10-21 20:32 ` Ada.Directories Markus E L 2007-10-21 23:52 ` Ada.Directories Robert A Duff 2007-10-22 11:08 ` Ada.Directories Harald Korneliussen 2007-11-15 11:44 ` Ada.Directories Markus E L 2007-11-16 13:27 ` Ada.Directories Dmitry A. Kazakov 2007-11-16 16:48 ` Ada.Directories Martin Krischik 2007-11-16 18:47 ` Ada.Directories Larry Kilgallen 2007-11-16 20:35 ` Ada.Directories Martin Krischik 2007-11-16 19:00 ` Ada.Directories Dmitry A. Kazakov 2007-10-21 1:25 ` Ada.Directories anon 2007-10-20 22:36 ` Ada.Directories Larry Kilgallen 2007-10-22 18:56 ` Ada.Directories Adam Beneschan 2007-10-23 9:04 ` Ada.Directories Peter Hermann 2007-10-23 12:07 ` Ada.Directories Larry Kilgallen 2007-10-23 13:01 ` Ada.Directories Peter Hermann 2007-10-23 16:08 ` Ada.Directories Robert A Duff 2007-10-23 17:11 ` Ada.Directories Larry Kilgallen 2007-10-24 0:55 ` Ada.Directories Brian May
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox