dos/MatchFirst sends ACTION_LOCATE_OBJECT for root to filesystem handler

[deadwood2]

If there is a file system handler that does not have a physical block/ram device behind it, then MatchFirst is still trying to "lock" the root of such handler like PIPE: or NOP: where on other amiga systems it does not do so. As NOP: handler does not implement this functionality because it is not required under AmigaOS, it reports failure under AROS. While issues is reported on 2017 ABIv0 build it was re-tested to be present also in current master (m68k and x86_64 versions)

Used software:

http://megaburken.net/~patrik/NOP-Handler_debug.aros-x86_64 and the DOSDriver definition from http://megaburken.net/~patrik/NOP-Handler.lha source https://github.com/patrikaxelsson/NOP-Handler
http://megaurken.net/~patrik/asum.aros-x86_64 source https://github.com/patrikaxelsson/asum

Behavior for copy:

AmigaOS 3.2.1 copy NOP:1K ram:test:
ACTION_LOCATE_OBJECT dp_Arg2: 'NOP:'
ACTION_IS_FILESYSTEM(1027), dp_Type: 0, dp_Arg1: 0x0, dp_Arg2: 0x403, dp_Arg3: 0x7000864
ACTION_FINDINPUT(1005), dp_Type: 30161619, dp_Arg1: 0x0, dp_Arg2: 0x1CB31CF, dp_Arg3: 0x7000864
Opening: 'NOP:1K'
ACTION_READ(82), dp_Type: 0, dp_Arg1: 0x737C274, dp_Arg2: 0x10000, dp_Arg3: 0x7000864
ACTION_READ(82), dp_Type: 0, dp_Arg1: 0x737C274, dp_Arg2: 0x10000, dp_Arg3: 0x7000864
ACTION_END(1007), dp_Type: 0, dp_Arg1: 0x1C7FFD5, dp_Arg2: 0x0, dp_Arg3: 0x7000864
Closing 0

Old 2017 AROS ABIv0 i386 copy NOP:1K
ACTION_LOCATE_OBJECT(8), dp_Type: 0, dp_Arg1: 0x1141f55, dp_Arg2: 0xfffffffe, dp_Arg3: 0x1001240
ACTION_LOCATE_OBJECT dp_Arg2: '' <---- issue
ACTION_LOCATE_OBJECT(8), dp_Type: 0, dp_Arg1: 0x1bb2a35, dp_Arg2: 0xfffffffe, dp_Arg3: 0x1001240
ACTION_LOCATE_OBJECT dp_Arg2: '' <---- issue

Behavior for asum:

AmigaOS 3.2.1 asum NOP:1K (Will do MatchFirst() only, no special stuff):
ACTION_FINDINPUT(1005), dp_Type: 30162691, dp_Arg1: 0x0, dp_Arg2: 0x1CB31CF, dp_Arg3: 0x7000864
Opening: 'NOP:1K'
ACTION_READ(82), dp_Type: 0, dp_Arg1: 0x73BA090, dp_Arg2: 0x10000, dp_Arg3: 0x7000864
ACTION_READ(82), dp_Type: 0, dp_Arg1: 0x73BA490, dp_Arg2: 0xFC00, dp_Arg3: 0x7000864
ACTION_END(1007), dp_Type: 0, dp_Arg1: 0x701B888, dp_Arg2: 0x1CC3F03, dp_Arg3: 0x7000864
Closing 0

Old 2017 AROS ABIv0 asum NOP:1K:
ACTION_LOCATE_OBJECT(8), dp_Type: 0, dp_Arg1: 0x247bad5, dp_Arg2: 0xfffffffe, dp_Arg3: 0x1001240
ACTION_LOCATE_OBJECT dp_Arg2: '' <--- issue

[deadwood2]

Additional comment:

'Comment no.2: I wonder if the first ACTION_LOCATE_OBJECT by AROS C:Copy is actually no problem, as it continues to the second ACTION_LOCATE_OBJECT - perhaps the first one is a manual Lock() by C:Copy which it handles fine if it fails, but second one is from MatchFirst() where it actually fails? AmigaOS C:Copy also attempt a Lock() initially as you can see in its log, which is not by MatchFirst() as we know it does not generate a Lock() for the handler DEVICE: case on AmigaOS'