API hole? No way to find the full path of a link that is in a multi-assignment?

This may seem quite obscure, but in trying to fix an issue with AmiSystemRestore I ran into what looks like a "hole" in AmigaOS's API:


For a given path, I normally Lock() a file & then use NameFromLock() to obtain the fully unambiguous ('expanded') version of that path. This is especially useful if you have a multi-assignment, such as:

Assign Foo: volume:one
Assign Foo: volume:two ADD

So that if I have the path "Foo:some_file", I can find out whether it is stored within volume:one or volume:two. (The result of NameFromLock() would be "volume:one/some_file" OR "volume:two/some_file".)

BUT, if I try to do that when "some_file" is a (soft) link, then I will get the 'expanded' path of the *destination* of the link. Sometimes this is what you want, but in this case I want to get the 'expanded' path of the original link file itself...

... and I don't think that is possible. Well, unless I start re-implementing AmigaDOS functionality by iterating through all the parts of the multi-assignment, looking for a matching file. But that seems complex, error-prone, and IMHO a sure sign of a "hole" in AmigaOS's API. So, did I overlook simpler way?

If I'm undertsanding what you saying correctly, you have something like

volume:one/somefile -> voulume:somewhere/destination

whwre volume:one is part of a multiassign FOO:

so expanding a lock on foo:some_file gets you

voulume:somewhere/destination

not

volume:one/somefile

??

I think that must be because the lock on the "link" is in reailty a lock on it;s destination.

How do obtain this lock? If you locked it yourself, then do a some test to see of the 'file' is a link, and lock it's parent instead. That may or may not actually work, but it;s the only idea I think of at the moment....

@broadblues
I think you basically understand my problem. Unfortunately your idea won't work (reliably).

What you are seeing is probably related to the way that soft links are implemented (or not) in that particular file system. All the old filesystems do it differently and there is little, if any, consistency between them.

Soft links and their semantics are one of the areas we are trying to refine and define at present.

Which version of dos.library are you running?

@tonyw
Are you saying that on some filingsystems, locking a soft-link will result in a lock on the soft-link itself, rather than the target file? (I would be surprised if that was the case, even though I know filingsystems can differ in other areas. The behaviour I am seeing makes sense to me as it is what you want in the common case - just not in my case!)

@ChrisH
I've been struggling with the same type of issues in a program I'm working on. The automatic link and multi-assign resolution in OS4 AmigaDOS might simplify things for simple file access but it makes some things more difficult for complicated file management. Here is one way to resolve your problem:

Use locktaglist() instead of lock() so you can tell if your lock was resolved through a link. If not, just proceed with your NameFromLock() call. If it was a link then you need to use GetDeviceProcFlags() to obtain the multiassign names and attempt to locktaglist() your file in each of the multi-assign directories to determine the exact location. Refer to the autodocs for the above mentioned functions.

I don't think my Autodocs even mention LockTaglist() :(

But I should be able to use ReadLink() to determine if something is a link or not (although it may not be as efficient, due to string stuff).

Thanks for the suggestion to use GetDeviceProcFlags(). It seems to be an OS4-only function... but I guess it should be possible to use GetDeviceProc() instead to check multi-assignment.

Quote:

That'll be because the SDK is 2-3 years out of date. The little pop-up menu you can have in window borders isn't available to any devs either for the same reason. I'm sure there must be other things that have been added but we have no access to.

I wrote: Quote:
I ended-up completely reimplementing my somewhat kludgy "expandPath()" procedure to use GetDeviceProc() (and NameFromLock() of course). It should now be much more robust, and in particular handle multi-assignments & links .

I also fixed my "easyReadLink()" procedure to also handle multi-assignments. It seems I already had the code snippets to do this, but never got around to integrating it...

Summary: AmigaOS does NOT have an API hole... although working out how to use ReadLink() (with or without GetDeviceProc()) isn't easy due to lack of documentation (I'm not sure how I originally found out either way).

I thought I had it working, but it turns out not

After calling GetDeviceProc(), DevProc->dvp_Lock is always NULL no matter which path I supply to GetDeviceProc(). Really wierd.

As a betatester, you have the latest dos.library and the latest documentation as well (included with the distributed archive). The documentation should all be in there somewhere.

I don't know where the boundary between the filesystem and DOS is in this case.
You know who to call...

@tonyw
I don't want to use LockTags(), if I can help it. And me being a beta-tester doesn't help anyone else like ChrisY...

Also, the docs don't explain why I'm always getting a NULL lock from GetDeviceProc(). EDIT: OK, it looks like DevProc->dvp_Lock is NULL *except* when the supplied path contains no volume/assign. Oh for some better documentation...

Quote:
If you have complaints about the autodocs you should be filing bug reports and Colin will take care of it.

We can also use assistance with the wiki for larger issues beyond the autodocs.

The dvp_Lock is the directory relative reference lock,
if you are not using a relative access, such as a VOLUME:
or DEVICE: root reference, it will be NULL.

You need to use an Assign, PROGDIR: CURRDIR: or APPDIR:
reference for dvp_Lock to be non-zero.

Quote:

Just for the record, I have no desire to use the window.class pop-up menu function, or LockTags for that matter (well, I have no idea what that does, so maybe I do want to use it and just don't know it yet?). However, there may well be new functionality I do want to make use of but don't know about. Without an updated SDK it is impossible to tell, and whilst I don't expect a new SDK to be released with every OS update, it would be nice for it to not trail massively behind the OS itself. If we could have an SDK update at least once a year, or some sort of regular update, that would help developers which then benefits the platform as a whole.

@ChrisY

Quote:

Yes, regular SDK updates would be great. In the meantime, keep an eye on the developer documentation in the AmigaOS Wiki. Work on updating the wiki is ongoing.

Hans

@ssolie Quote:
Until I know what I don't understand, it's hard to say anything useful about how the documentation could be improved.

@myself Quote:
OK, thanks to "MultiAssign.txt" & "multilist.c" (from Amiga Mail Vol 2), I think that I finally understood what is happening, although I'm still not 100% sure:

When dvp_Lock is NULL, it is indicating that the root directory of the "default device" (or "default filingsystem") should be used. For a normal process this is simply SYS:, but it seems that when using a lock from GetDeviceProc() you are expected to change the "default device" to the one currently specified by DevProc, i.e. dvp_Port . Thus you need to do something like this before using the (NULL) lock:

oldFSPort = SetFileSysTask(devproc->dvp_Port)
/*and restore the old setting afterwards*/


The aforementioned "multilist.c" also revealed that the documentation & earlier examples showing the checking of IoErr() status & dvp_Flags for DVPF_ASSIGN on every use of GetDeviceProc() are wrong (or at least no-longer needed since about OS2.x). All you need to check for is whether GetDeviceProc() returns NULL, and then perhaps check IoErr() once after that happens.

In fact, the documentation is very misleading about dvp_Flags, because it can be interpreted (wrongly!) as saying that when dvp_Flags contains DVPF_ASSIGN you should immediately call GetDeviceProc() again (and thus ignore the last returned DevProc). What I discovered is that DVPF_ASSIGN is set for all but the last assignment in a multi-assignment. So you *could* check for DVPF_ASSIGN as an indication that you need to call GetDeviceProc() again, but that is entirely unnecessary, and certainly does not mean you should ignore that particular DevProc!

Quote:
The SDK update problem will be solved shortly.

@ssolie

to stay in line with your avatar...

Homer: "Woohoo!"