AmigaDos Links
6 messages in this thread
Although not specifically a C problem: I have tried to use the makelink
feature of AmigaDos to create links to common files in different
directories allowing me to maintain directory contents but make specific
files available to other programs without adding a zillion directories to
my path list. PROBLEM: how can these be maintained. A listing doesn't
indicate that these are links and not real files. There doesn't seem to
be a way to list only link files etc. I've been using DG's AOS/VS on
MV15000's with their link environment.
You should be able to use ADOS's directory scanning calls to get the file types
for all the entries in a specified directory. From there, you'll be able to
find the file link entries. I don't have my DOS book with me, so I can't be
more specific right now.
Not sure what you mean when you ask "How can these be maintained?"
Conceptually, 'hard' links are not really links, they are real files. ie., if
you make a file, then make a hard link to that file, then delete the filename
that was a hard link, you are left with a real file. If you delete the
original, you are left with a real file.
-larry
Larry, re Links.
For example I have gadtoolsbox in a subdirectory of my compiler partition.
The default path when the program creates the project file is
:gadtoolsbox. Thus I use a link from :gadtoolsbox to the appropriate
subdirectory and never have to modify the tool path in the created project
info files. However, the link shows up to workbench as if it were the
destination file. In CLI using list the characteristics show as if it were
the destination file. There is no way using these two approches to tell a
link is in use. The which command shows the destination file which is as
expected. I finally tried the dir command which shows a <hl> after the
name of the link. There is no way just to show link files as there is for
files and directories. The dir command doesn't also indicate the immediate
link destination which would be a plus. Multiple links are possible but
it is impossible to find the name of any secondary etc links. This would
seem to be important to maintaining a system which uses links. I have
worked on system which use a link file as a file selector which is in turn
linked to from other directories, not easy to track here.
James,
Yes, I understand, but in reality, but again, a hard link is not really a
link. If the link or the original file is deleted, the file remains. Try making
a link to a file, then delete the original. The one that's left, that used to
show up as a link, is now a file like any other file. In other words, the
assignment of the status of <hl> when doing a DIR, is arbitrary. Any of the
filenames (directory entries) that refer to the same data, are potentially the
real file (if you define real file as the file that does not have a <hl> after
it when you do a DIR).
-larry
Larry,
You are right! I couldn't seem to get the pointer out of my head after
all thats what it says in the manual. I should remember manuals are only
a last resort. Thank for clearing it up before it got out of hand.
Jim