"Use"d settings: application behaviour

[thomasrapp]

Actually, I think it a misunderstanding that ENVARC: should be used for permanent program settings. Every time I boot or reboot, 70K of 3rd party prefs get copied to ENV: and there's not much I can do about it.

This only applies to OS3. OS4 has Env-Handler. It does not copy anything to RAM. Only changed variables are held in RAM.

But yes, I agree, using ENV/ENVARC for temporary/permanent settings should only be done by programs which have a similar life time and usage as Workbench.

[xenic]

This only applies to OS3. OS4 has Env-Handler. It does not copy anything to RAM. Only changed variables are held in RAM.

OS4 ENV: may not be in RAM: but it appears to be copying everything except some ENVARC:Sys files. If you enter "Dir ENV:" in a shell you will see the same directory structure as in ENVARC: (including comments). If you enter "List ENV:" in a shell you will see all the files and their sizes. You can also copy files to ENV: and delete files from ENV: as well.

If you look at SYS:Kickstart/env-handler.kmod in a Hex editor you will see:
"$VER: env-handler 52.2 (30.12.2006) Copyright 2001-2006 by Stephan Rupprecht".
If you visit Stephen Rupprecht's WEB site you can download env-handler.lha and find in env-handler.doc the description "env-handler is a RAM disk specialized for enviroment variables".

The fact that env-handler is a "RAM disk" implies that the files you see when you list the contents of ENV: have actually been copied there.

[nbache]

OS4 ENV: may not be in RAM: but it appears to be copying everything except some ENVARC:Sys files.

You would think so by looking at ENV:, but that is exactly the neat thing about env-handler. It doesn't copy any file from ENVARC: to ENV: until someone accesses that particular file in ENV:.

Best regards,

Niels

[chris]

OS4 ENV: may not be in RAM: but it appears to be copying everything except some ENVARC:Sys files.

You would think so by looking at ENV:, but that is exactly the neat thing about env-handler. It doesn't copy any file from ENVARC: to ENV: until someone accesses that particular file in ENV:.

ISTR that's why I installed it under OS3. The old copy process adds a fair bit of time to boot, OS4 is definitely not copying ENVARC: to ENV:

[xenic]

OS4 ENV: may not be in RAM: but it appears to be copying everything except some ENVARC:Sys files.

You would think so by looking at ENV:, but that is exactly the neat thing about env-handler. It doesn't copy any file from ENVARC: to ENV: until someone accesses that particular file in ENV:.

ISTR that's why I installed it under OS3. The old copy process adds a fair bit of time to boot, OS4 is definitely not copying ENVARC: to ENV:

Really? I think you're just believing what you've been told instead of testing. Here is one of the tests I tried:

Open a Shell and enter:
SetEnv SAVE MYVAR 9999

Warm Reboot

Open a Shell and enter:
echo >ENVARC:MYVAR 1111
type ENVARC:MYVAR
1111

GetEnv MYVAR
9999

How did the last GetEnv get a value of 9999 unless that value had been copied to ENV: during the boot process?? I changed the value of MYVAR in ENVARC: with "echo >ENVARC:MYVAR 1111" and confirmed that value with "type ENVARC:MYVAR". The last "GetEnv" had to get the value "9999" from somewhere and I'm saying that it got the value in ENV: that was copied there during the reboot.

[nbache]

Really? I think you're just believing what you've been told instead of testing.

Guilty as charged. I can confirm your test case.

How did the last GetEnv get a value of 9999 unless that value had been copied to ENV: during the boot process?

I haven't been able to find any documentation about that, but one possibility is that env-handler copied it at the start of the access to ENVARC:MYVAR, before it was changed.

Best regards,

Niels

[xenic]

haven't been able to find any documentation about that, but one possibility is that env-handler copied it at the start of the access to ENVARC:MYVAR, before it was changed.

So you're saying that when you change a variable in ENVARC: env-handler grabs the old value right before it changes and puts the old value in ENV: instead of the new value? That sounds pretty far fetched to me; not to mention the fact that getting the old value instead of the new one is logically backwards. Come on man, this isn't a religious belief that can't be challenged.

O.K. Here's another test to confirm my contention that most of the ENVARC: data is copied to ENV: during a boot:

Create a bootable USB Flash drive.
Boot from the USB Flash drive.
Open a shell and enter SetEnv SAVE MYVAR 9999.
Reboot from the USB Flash drive.
Open a shell.
Remove the USB Flash drive.
In the shell you opened enter GetEnv MYVAR.
The result in the shell window will be 9999.

How do you get the value of 9999 for MYVAR if the variable wasn't already in ENV: after booting? I guess somebody is going to tell me that the env-handler read my mind and grabbed it before I removed the Flash drive

[colinw]

How did the last GetEnv get a value of 9999 unless that value had been copied to ENV: during the boot process??
I changed the value of MYVAR in ENVARC: with "echo >ENVARC:MYVAR 1111" and confirmed that value with "type ENVARC:MYVAR".
The last "GetEnv" had to get the value "9999" from somewhere and I'm saying that it got the value in ENV: that was copied there during
the reboot.

The way ENV: works is like this ...
When a variable is accessed via the ENV: device, and it is not already there, the corresponding path to the file is locked in ENVARC:
and the copy of the variable is created in ENV: if it actually exists in ENVARC:

The reason your test did what you observed, is because something in the startup-sequence scanned that particular
directory level, this causes a directory preload, because just returning an empty directory would be somewhat sub-optimal.

Here's some of my comments from the env-handler source code, for the ExamineDir() function.....
/*
** We can't scan objects that aren't there yet, so, if this directory has not been preloaded before,
** we have to do it before we itterate the list of possible objects. cjw.
*/

If you broke the startup-sequence at the boot cli and did the same test, it would likely work as you expect,
providing some RTF_AFTERDOS module doesn't also do an ENV: directory scan.

[nbache]

haven't been able to find any documentation about that, but one possibility is that env-handler copied it at the start of the access to ENVARC:MYVAR, before it was changed.

So you're saying that when you change a variable in ENVARC: env-handler grabs the old value right before it changes and puts the old value in ENV: instead of the new value? That sounds pretty far fetched to me; not to mention the fact that getting the old value instead of the new one is logically backwards.

I'm not claiming it is logical, just that it is a possibility that this is how things happen to work in your very special case.

Remember that env variables are supposed to be changed by using SetEnv, with the SAVE switch if you want to change it permanently, and without if you only want to change it for the duration of your session. The behaviour of modifying the saved value by direct manipulation is not necessarily defined.

And why would you? If you respond "For curiosity", then all is forgiven, otherwise, I'd like to see a practical case where this would be useful to do.

Best regards,

Niels

Edit: Okay, I have now read Colin's explanation above and therefore conclude that my possible explanation is not the real one. I still claim that my logic holds, though .

[nbache]

To wipe away any further speculation, I tried the following test:

$ Setenv SAVE level1/level2/myvar 9999

Reboot

$ echo > ENVARC:level1/level2/myvar 1111
$ getenv level1/level2/myvar
1111
$

Best regards,

Niels