DOS request for unavailable device

[tonyw]

Open the file ENVARC:Sys/AmiDock.amiga.com.xml and look inside it for references to Work2: (you should have seen this when you did the Find earlier).

One of the problems with AmiDock is that when you drag an icon and drop it on the Dock, it writes down the absolute path of the object, not the SYS:... path, so you have to edit paths of things you've dropped from Work: to SYS: if you are going to change the name of Work: or copy the amidock xml file to another system.

[Amigo1]

Open the file ENVARC:Sys/AmiDock.amiga.com.xml and look inside it for references to Work2: (you should have seen this when you did the Find earlier).

One of the problems with AmiDock is that when you drag an icon and drop it on the Dock, it writes down the absolute path of the object, not the SYS:... path, so you have to edit paths of things you've dropped from Work: to SYS: if you are going to change the name of Work: or copy the amidock xml file to another system.

yes, did that. I loaded the AmiDock prefs file in NotePad and searched for "work2" and "work" (no case sensitive search, so "Work" or "WoRk" would have been found too). I really looked into every prefs file in ENVARC: and it subdirs. I checked everything in S: and subdirs, I checked the SDK startup and every other script called from the User-Startup.

This is really, really puzzling me!

[tonyw]

I just had a similar "problem" on one of my test partitions. I had created a soft link on that partition to a disk icon on the system partition (which was called "NewUpdate3:").
Then I renamed the system partition to "BetaSystem:" and checked the newly renamed partiton for any references to "NewUpdate3" (there was none). So far, so good, but after a day or two I was annoyed to find that when I tried to open the test partition, it always asked me for "NewUpdate3:". Grrr, I know there are no references to that name anywhere...

I eventually found the soft link on the test partition, deleted it and formed a new one pointing to the new system name, all OK.

So, the moral is that even if you search everywhere, there are some references to the old system name that you will not see. For instance, you can't see the target of a soft link unless you list it, in which case a link whose target has changed will become an "unresolved softlink".

Despite what someone said earlier, softlink targets are not stored in the comment field of a file, they merely appear in the same place in a listing. The only way you can see what a soft link refers to is to list it or try to resolve it (as Workbench does when you try to open the directory containing the link).

So have a look in the offending partition and list it in a Shell. You'll soon see if there are any soft links.

[Amigo1]

I just had a similar "problem" on one of my test partitions. I had created a soft link on that partition to a disk icon on the system partition (which was called "NewUpdate3:").
Then I renamed the system partition to "BetaSystem:" and checked the newly renamed partiton for any references to "NewUpdate3" (there was none). So far, so good, but after a day or two I was annoyed to find that when I tried to open the test partition, it always asked me for "NewUpdate3:". Grrr, I know there are no references to that name anywhere...

I eventually found the soft link on the test partition, deleted it and formed a new one pointing to the new system name, all OK.

So, the moral is that even if you search everywhere, there are some references to the old system name that you will not see. For instance, you can't see the target of a soft link unless you list it, in which case a link whose target has changed will become an "unresolved softlink".

Despite what someone said earlier, softlink targets are not stored in the comment field of a file, they merely appear in the same place in a listing. The only way you can see what a soft link refers to is to list it or try to resolve it (as Workbench does when you try to open the directory containing the link).

So have a look in the offending partition and list it in a Shell. You'll soon see if there are any soft links.

ok, this might have solved it, I will report in a few days. I did find one soft link pointing to a dir in "Work2"
Thanks a lot mate!

And thanks to using C:List I found some glitches with it.. not sure if I should open a new thread about it.. Well I'll post it here in the meantime:

Glitch Nr. 1: List does not list files in dirs with round brackets and quits with an error.
C:List (53.1) seems to have problems with round brackets. I know round brackets are special characters which
should not be in AmigaDOS filenames, but nowadays files from other systems happen to be copied over.
For example the game "Lugaru" has some drawers with round brackets, renaming them will prevent lugaru from
working properly. Another App using round brackets is AMC (Amiga Media Centre).

eg:
Make a new dir in RAM: rename it to "Rename_Me(hh)"
then type in the following in a shell:
list ram: all

One of the appearing text lines will tell you:
LIST: No information for "RAM:Rename_Me(hh)
LIST: object not found

Glitch Nr. 2: The option LIST LFORMAT "%R" does not always work. or is it supposed to work like this:
This is the Output of a shell::

Code: Select all

11.AmigaOS:>CD SYS:SObjs/
11.AmigaOS:SObjs>list libpng.so lformat "%F%N"
AmigaOS:SObjs/libpng.so
11.AmigaOS:SObjs/list libpng.so lformat "%F%N %R"
AmigaOS:SObjs/libpng.so
11.AmigaOS:SObjs>List SOBJS: lformat "%F%N %R"
----snip----
AmigaOS:SObjs/libpng.so SYS:sobjs/libpng12.so
----snip----

As you can see, the links are shown only if a directory is listed, but not if only one file.

I also noticed only Softlinks show the path to the file they are linked to, hardlinks are not highlighted.
Mmmh.. thinking about it, it makes sense, as it is "just a node pointing to the same data".

[xenic]

As you can see, the links are shown only if a directory is listed, but not if only one file.

It's not just a problem with the LFORMAT %R option. The list command doesn't show the link if you list the file using the exact filename like "list libpng.so". If you throw a wildcard into the filename like "list libpng.s?" then the link is shown. This seems like a bug to me and should probably be reported.

[xenic]

@Amigo1

List does not list files in dirs with round brackets and quits with an error.

If you place a file in your test directory and list the directory by name like:
list "Rename_Me(hh)"
the list command shows nothing. However add some wildcards like:
list "Rename_Me????"
and the directory contents are listed.

I'd say this is another bug that should be reported. It seems the "list" command needs a little work before the next OS4 update or release.

[Amigo1]

@Amigo1

List does not list files in dirs with round brackets and quits with an error.

If you place a file in your test directory and list the directory by name like:
list "Rename_Me(hh)"
the list command shows nothing. However add some wildcards like:
list "Rename_Me????"
and the directory contents are listed.

I'd say this is another bug that should be reported. It seems the "list" command needs a little work before the next OS4 update or release.

yes, it is a bit annoying if you try something like:

list work: all >RAM:testlist.txt

it fails and quits as soon as some directory with the mentioned pattern appears.

Where to report the bug?

[tonyw]

This has gone off topic and deserves a new thread. However, I don't think it's a "List" or "Dir" or "Delete" problem - it looks more like a general DOS parsing problem.

Please raise a new thread and we can get the DOS author involved.