Yes, the system can make hard links. But it looks like it can't identify them yet?
I just tested it again with my test executable, it does definately work with the latest dos.library,
you didn't say what version you are using, it may have issues that have subsequently been fixed.
Code: Select all
8.RAM Disk:__testdir> examinedir ""
harddirlink HARDDIR LINK --> dir2 [RAM Disk:__testdir/dir2]
hardfilelink HARDFILE LINK --> file2 [RAM Disk:__testdir/file2]
softdirlink SOFT LINK --> dir1 [RAM Disk:__testdir/dir1]
softfilelink SOFT LINK --> CURRDIR:file1 [RAM Disk:__testdir/file1]
file2 FILE Size 50
file1 FILE Size 50
(*) The first result after --> shows exd->Link contents.
(**) Square brackets show the result from NameFromLock()
I'm not sure how old your ExamineDir function autodocs in the SDK are, but it has been updated with a lot more
example code since earlier versions, so here is some relevant info from the latest one, I hope this helps resolve
your issue, if not reply back.
* Linked Objects:
* When performing a directory scan using this function, the link entries
* in the listing will appear as soft or hard links, optionally,
* the examinedata->Link field will show the target name if that flag
* option is enabled. (EXF_LINK)
* Softlinks are resolved by DOS and may point to targets on other volumes.
* Hardlinks are resolved by the filesystem itself and are limited to
* target objects on the same volume as the links.
* Softlinks can be "broken", in that the target may no longer exist at
* the target specification. Hardlinks cannot be in a "broken" state.
* Softlinked directories can point to a target directory above the
* links directory, thereby causing an infinite recursive loop.
* All DOS API functions use a softlink counter and limit the number of
* softlinks in any path to a maximum of 15 (currently), if that is
* exceeded the function will fail with error code; ERROR_TOO_MANY_LEVELS.
* Hardlinked directories cannot have targets created that point to a
* level above the link directory, this means they cannot cause a loop.
* However, this protection MAY NOT be implemented with older packet based
* filesystems, so be carefull when recursively scanning a directory,
* or better still, don't enter any linked directory unless specifically
* told to do so, and then, only do it once.
* Softlink Targets:
* Always set EX_DoCurrentDir,TRUE tag in the ObtainDirContext() call when
* testing softlinks, this sets the current directory correctly for the
* ExamineObject() call which is used to obtain target object information.
* Softlink targets specifications in Examinedata->Link are usually link
* directory relative paths, but can instead contain information which
* specifies a path to another volume, that volume may or may not be
* currently mounted, so it is recommended that DOS requesters be disabled
* during the ExamineObject() call to prevent the appearance of the
* "Please Insert Volume..." requester. See also; SetProcWindow().
* If you got what you wanted, you should display the target data and type
* of object in the directory listing like Workbench, the ASL file requester,
* the Dir and List commands, etc. do.
* Hardlink Targets:
* Hardlinks are automatically handled by the filesystem, other than being
* identified by the examinedata->Type, they behave just like real files
* and directories. For purely semantical reasons, the filesystem will
* copy the target object name (no DOS path) into the examinedata->Link
* buffer, if that flag option is enabled. (EXF_LINK).
* This string cannot be used to resolve the hardlink target path.
* To obtain a fully qualified DOS path to the target of a hardlink,
* Lock() the examinedata->Name and call the [Dev]NameFromLock() function,
* for additional target information, call ExamineObject() using the same
* lock, don't forget to UnLock() it afterwards.