Mysterious environmental variable

[xenic]

Whenever I run Ranger a strange environmental variable appears in ENV: that cannot be removed after I quit Ranger. The variable constists of a "1" followed by 106 "z" (i.e. 1zzzzzzzzzzzzz ...). The variable is empty. I can't delete the variable or remove it with Unsetenv. Is this a bug in the ENV device?

[tonyw]

You should be able to delete it with "delete ENV:1zzz#?"

What version of env-handler are you running?

[xenic]

You should be able to delete it with "delete ENV:1zzz#?"

That's what I thought but it doesn't work. Delete reports "Not Deleted: object not found".
On the other hand "list ENV:#?" works and returns this:

1zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz empty ----rwed Today 09:18:51
1 file - 1 block used

You can D/L Ranger from OS4Depot and try this for yourself. Maybe Solie (Ranger author) can tell us why it's creating and environmental variable that can't be removed.

What version of env-handler are you running?

On my SAM Flex I have version 52.2 (12/30/2006).

[nbache]

What version of env-handler are you running?

On my SAM Flex I have version 52.2 (12/30/2006).

Yeah, that's the correct one for a 4.1 update 4 installation.

I just tried booting my "clean" update 4 partition on the A1 and starting Ranger, and I see no such env variable.

Best regards,

Niels

[Spectre660]

I had this once. Cant remember what casued it. It may have been a 68k app like Turbosprint.

You should be able to delete it with "delete ENV:1zzz#?"

That's what I thought but it doesn't work. Delete reports "Not Deleted: object not found".
On the other hand "list ENV:#?" works and returns this:

1zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz empty ----rwed Today 09:18:51
1 file - 1 block used

You can D/L Ranger from OS4Depot and try this for yourself. Maybe Solie (Ranger author) can tell us why it's creating and environmental variable that can't be removed.

What version of env-handler are you running?

On my SAM Flex I have version 52.2 (12/30/2006).

[tonyw]

If you can't delete it (Object not found), that is probably because the filename is the maximum legal length and the comparison is failing (there were such bugs in a number of the older filesystems).

You could also try to rename it to "junk", then "delete junk".

I can't see that variable here after I run Ranger, but then I don't know what you are doing with it. Are you just starting Ranger, then exiting without doing anything?

[xenic]

I just tried booting my "clean" update 4 partition on the A1 and starting Ranger, and I see no such env variable.

What version of Ranger are you using? I'm using the latest from OS4Depot; version 1.52.

I think I've figured out what is going on and it's not a problem with the ENV device. It's a combination of something Ranger is doing and a quirk (bug?) in AmigaDOS. I used Snoopy to check what Ranger is doing and could only find 2 possible accesses to ENV: while Ranger is starting. One is to add a variable to ENV:AppPaths and the other is to check if ENV: is "interactive". Ranger checks all system devices to see if they are interactive. IDos->IsInteractive() requires a file handle as it's argument so I'm guessing that Ranger is opening a file in ENV: to check if it's an interactive device. Some devices (like AUX:) will allow you to open it at the device level but ENV: seems to only return a file handle if you append a filename to the device name when you attempt an IDOS->Open(). Apparently Ranger is using the filename "1zzz ...", but it's 107 characters long. IDOS->Open() lets you open a file that is 107 characters long, but AmigaDOS "Delete" (and Dopus4) can only use filenames up to 106 chars long. The only way to delete the file is with "Delete 1zzz#?". I tested the same issue using "RAM:" and the same thing occurs. I can open a file in RAM: that has a filename 107 chars long and can only be deleted using a wildcard delete.

If I'm right and Ranger is using a 107 char filename, then Solie needs to use a smaller filename in Ranger. If it's being done by some library or device that Ranger is opening then there is no way I can tell where it's coming from. I think the best solution is to change AmigaDOS so that IDOS->Open() respects the same maximum filename length as the rest of the system.

EDIT: tonyw identified the problem before I finished my post but it still needs to be fixed. You shouldn't be able to create a file that can't be deleted in the normal way (i.e. delete "file").

[xenic]

If you can't delete it (Object not found), that is probably because the filename is the maximum legal length and the comparison is failing (there were such bugs in a number of the older filesystems).

You could also try to rename it to "junk", then "delete junk".

I can't see that variable here after I run Ranger, but then I don't know what you are doing with it. Are you just starting Ranger, then exiting without doing anything?

Yes. I think filename length is at the root of the problem. Maybe others aren't seeing the problem because they are using a different version of Ranger or are beta testers and the filename length problem has been fixed in a newer version of AmigaDOS. It could be that Ranger is deleting the file but it isn't working on my system because I have an older AmigaDOS. I have added all the OS4.1 updates to my system so I'm using the latest publicly available files.

EDIT: Yes. I'm just starting Ranger and quitting.

[tonyw]

Env-handler V52.2 is obsolete anyway. It has been rewritten and is currently in beta test stage. The 108-character limitation has long gone. All filesystems these days can handle 256-character names.

I realise that doesn't fix the fault (being able to create a file that you can't delete), but I assure you that the new version does not suffer from that problem.

[xenic]

@tonyw
It's been fixed in all the shell commands? The C: commands I've tested seem to be limited to 106 chars but if that's been fixed then I'll be glad to get the next OS4.1 update.