AmigaOS 4.1 Update 2 and 3 changed semantics of AssignLock DOS call

A forum for general AmigaOS 4.x support questions that are not platform-specific
Post Reply
FlynnTheAvatar
Posts: 5
Joined: Thu Aug 11, 2022 1:41 pm

AmigaOS 4.1 Update 2 and 3 changed semantics of AssignLock DOS call

Post by FlynnTheAvatar »

Hi,

AmigaOS 4.1 Update 2 and 3 changed the semantics of the AssignLock DOS call.

Before Update 2 and on OS 2.x/3.x AssignLock("foo", 0L) would return DOSTRUE (-1L) if the assign does not exist. Starting with Update 2, it returns DOSFALSE (0L).

This breaks the ccselect tool of Cubic IDE for example.

Please restore the compatibility to 3.x and return DOSTRUE in case the assign does not exist. After the call the assign still does not exist, so it does not make sense that the call "failed".

Test case:

Code: Select all

/* compile with
 * vc +aos68k test.c -o test
 * ppc-amigaos-gcc -D__USE_INLINE__ test.c -o test
 */
#include <proto/dos.h>
#include <dos/dos.h>

int main() {
    char *assign = "foo";

    // clear Assign
    if (AssignLock(assign, 0L)) {
        Printf("Assign '%s' cleared.\n", assign);
    } else {
        Printf("Could not clear Assign '%s'. Reason: %ld\n", assign, IoErr());
    }

    return 0;
}
Result on Update 3 (X5000):

Code: Select all

3. > Work:Cubic IDE/ide/devkits/tools/ccselect/bin > assign | grep foo
3. > Work:Cubic IDE/ide/devkits/tools/ccselect/bin > assign foo:
Kann 'foo' nicht abbrechen.
3. > Work:Cubic IDE/ide/devkits/tools/ccselect/bin > test
Could not clear Assign 'foo'. Reason: 0
Result on Update 1 (AmigaOne):

Code: Select all

1. > assign | grep foo
1. > assign foo:
1. > test
Assign 'foo' cleared.
Thanks,
Josef
User avatar
colinw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 225
Joined: Mon Aug 15, 2011 10:20 am
Location: Brisbane, QLD. Australia.

Re: AmigaOS 4.1 Update 2 and 3 changed semantics of AssignLock DOS call

Post by colinw »

This was actually a long standing bug and was fixed back in 54.81 -- That's 7 years ago. !!

If I remember corectly, it was noticed by someone when using the "Assign" command
where it failed to return an appropriate return code for; "Assign foo: REMOVE"
Where the REMOVE option was added as a synonym for "Assign foo:"

=====================
dos 54.81 (12-10-2018)
- RemAssignList() never checked the 'lock' argument for NULL, it does now.
- Removing an assignment that didn't exist returned success instead of a failure code
via the functions; AssignLate(), AssignLock() and AssignPath().
=====================

So, why on earth would you want OS3 bugs added back into OS4 ?
Backward 68K compatibility surely has its limits.

Wouldn't it be better to just fix the application or better still,
don't try to remove assignments that aren't there. ?

If you want, you could make the assignment before trying to remove it,
then the point is moot. And No, i'm not joking.

I couldn't imagine the havoc that would be caused in other functions,
for example, if Delete() said it worked on a non-existing file,
or Open() returned success even though the file couldn't be opened for some reason.
FlynnTheAvatar
Posts: 5
Joined: Thu Aug 11, 2022 1:41 pm

Re: AmigaOS 4.1 Update 2 and 3 changed semantics of AssignLock DOS call

Post by FlynnTheAvatar »

The behavior has been been the same since V36 (2.0). And sure, every developer will now race to fix their > 15 years old code because you finally fixed this bug.

I do not have the source code of ccselect, and I do not think that Dietmar will ever update Cubic IDE again, and even then OS 4.1 was never a fully supported target.

If you really think this how it should be, please
  • document this in the Autodoc. Breaking fixes/changes should be documented in Autodoc.
  • add a corresponding error code to IoErr(). Because reason 0 is not helpful.
  • and maybe fix the translations for the assign error message. Because abbrechen != remove.
User avatar
colinw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 225
Joined: Mon Aug 15, 2011 10:20 am
Location: Brisbane, QLD. Australia.

Re: AmigaOS 4.1 Update 2 and 3 changed semantics of AssignLock DOS call

Post by colinw »

FlynnTheAvatar wrote: Fri Oct 31, 2025 11:12 am
  • document this in the Autodoc. Breaking fixes/changes should be documented in Autodoc.
  • add a corresponding error code to IoErr(). Because reason 0 is not helpful.
  • and maybe fix the translations for the assign error message. Because abbrechen != remove.
Now you make good points here;

1) The autodoc BUG section has been updated, it was missed for some reason back then.
2) I just checked and you are correct, IoErr() was not set for this specific error exit. Good find.!!
3) The translation is not my department, also I don't speak German very well, so i'll leave that
to the experts in that particular area.

Thanks for the report.
FlynnTheAvatar
Posts: 5
Joined: Thu Aug 11, 2022 1:41 pm

Re: AmigaOS 4.1 Update 2 and 3 changed semantics of AssignLock DOS call

Post by FlynnTheAvatar »

Thanks a lot, colinw!

Regarding the translation, I am not a native English speaker, but the error message 'Can't cancel "<assign>"' should be updated to 'Cannot remove assign "<assign>".'. And a proper German translation would be 'Kann Assign "<assign>" nicht entfernen.'.

Will the updated Autodoc be part of the next SDK release?
User avatar
colinw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 225
Joined: Mon Aug 15, 2011 10:20 am
Location: Brisbane, QLD. Australia.

Re: AmigaOS 4.1 Update 2 and 3 changed semantics of AssignLock DOS call

Post by colinw »

Yes, absolutely.
Every new SDK release always has the latest includes and autodocs.
FlynnTheAvatar
Posts: 5
Joined: Thu Aug 11, 2022 1:41 pm

Re: AmigaOS 4.1 Update 2 and 3 changed semantics of AssignLock DOS call

Post by FlynnTheAvatar »

Hi colinw,

I just installed the newly released SDK 54.25 today and checked the DOS autodocs again. Unfortunately, I still don’t see any updates in the AssignLock/RemAssignList BUG section.

Additionally, IoErr() is still not being set for this failure mode. I assume this requires an OS update rather than an SDK update, which is understandable.

Just wanted to provide this feedback so it doesn’t get lost. If the corrected autodocs or the missing IoErr() handling are planned for a future OS/SDK release, that would be great to know.
User avatar
colinw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 225
Joined: Mon Aug 15, 2011 10:20 am
Location: Brisbane, QLD. Australia.

Re: AmigaOS 4.1 Update 2 and 3 changed semantics of AssignLock DOS call

Post by colinw »

I don't know what went wrong, but the latest docs on the SVN are the latest with the BUG notes.
It would seem that these docs were compiled for the SDK archive before the updates were made.
This SDK has been in production for some time, with multiple people building it.
Nevertheless, it will undoubtedly appear in the next one.
Here is the current autodoc for AssignLock()...


/****** dos.library/AssignLock ************
*
* NAME
* AssignLock -- Creates a DLT_LOCK assignment to a locked object (V36)
*
* SYNOPSIS
* int32 success = AssignLock(CONST_STRPTR name, BPTR lock);
*
* FUNCTION
* Sets up an assign of a name to a given lock.
* Passing ZERO for a lock cancels any outstanding assigns to that name
* as well as all multiassignments that may be bound to it.
*
* If an assign entry of that name is already on the list, this routine
* effectively replaces that entry.
* If an entry is on the list that conflicts with the new assign,
* then a failure code is returned.
*
* NOTE: you should not use the lock in any way after making this call
* successfully. It becomes the assign lock, and will be unlocked by the
* system when the assign is removed. If you need to keep the lock,
* pass a lock from DupLock() to AssignLock().
*
* INPUTS
* name - Name of assignment to assign lock to (without trailing ':')
*
* lock - Lock associated with the object name for the assign. (or 0).
*
* RESULT
* success - Success/failure indicator.
* On failure, the lock is not unlocked.
*
* NOTES
* From V50, 'name' is tested for NULL and now causes IoErr() to
* return ERROR_REQUIRED_ARG_MISSING if this occurs.
*
* BUGS
* A long standing bug was finally fixed in 54.81, in that cancelling
* a non-existing assignment previously returned a success indicator.
* Now it returns failure but IoErr() was left unset (0) until 54.137,
* where IoErr() now returns; ERROR_OBJECT_NOT_FOUND.
*
* SEE ALSO
* Lock(), AssignAdd(), AssignPath(), AssignLate(), DupLock(),
* RemAssignList()
*
************************************************************************
*/
FlynnTheAvatar
Posts: 5
Joined: Thu Aug 11, 2022 1:41 pm

Re: AmigaOS 4.1 Update 2 and 3 changed semantics of AssignLock DOS call

Post by FlynnTheAvatar »

Hi colinw,

thanks a lot for the updated autodoc -€” much appreciated. I'€™ve updated the entry locally for now.

One more question: I understand that the developers working on AmigaOS 3.x and 4.x are not necessarily the same people. Still, do you know whether this fix is planned to be backported to AmigaOS 3.2.x or 3.3 as well?
Post Reply