Internet prefs

[OldFart]

Keeping a system partition clean by write-protecting it is a highly recommended move.

No it isn't, unless you want an actively broken system. Environment variable wont work, appdir wont work, internet prefs wont work (you wonr be able to setup new serveices etc).

Ah, now I know why my Micro never refused to boot! Thanks for clearing that one up. I always wondered how and why all those other users had the weirdest troubles with their system. Hah, kidding!
Be smart, keep your system partition(s) clean as a whistle and lock those partitions up to the point of barring the doors with sandbags. I kid you not (this time). And again: C:MakeDir is an undervalued friend and ally.

OldFart

[xenic]

No, it doesn't do that. Ram: is explictly ignored by the appdir server.

Either AppDir: has improved since it was introduced or I was completely mistaken when I first analyzed how it worked. It does however create entries for all commands/programs that are in the system path but apparently checks the system path before checking for an entry in the AppDir: directory; making those entries somewhat useless. Either way, I've had it disabled since it was introduced and it hasn't caused any problems. I've had my system partition write protected since I first encountered Amiga viruses and bad program installers.

[gazelle]

@xenic:

It's more for 3rd party support. eg: Someone installed "mplayer" somewhere (not in the system path). After it's launched once, APPDIR: knows it. Any other 3rd party program (or project icon) can now just use "APPDIR:mplayer" to use it, no matter where it is installed.

[tonyw]

... but apparently checks the system path before checking for an entry in the AppDir: directory; making those entries somewhat useless.

I think you'l find that is not the case. If you type a command name, it will search AppDir: first, then the system path. If it didn't, that would, as you say, render it useless.
The intent is that whichever version of your program you used last (and wherever it is) DOS will load that last-used version in preference to that from the system path.

Dump a test program into Dir A: and C:, then go to Dir B. Type the name of your test program and it will run the version from C:.
Type the fulll path of the version from Dir A: and it will run that version.
Now (still in Dir B), type the name of the test program again, but without the fulll path. It does not run the version from C:, but from Dir A:.

Try it with a script that echoes its own dir.

[colinw]

For those of you that are sufficiently paranoid about "evil things" overwriting files on your boot partition
and want to keep it write protected to stop nasty things playing around with your software.

Rather than banging on and on about how you hate something, have you actually considered that partially
crippling some OS features that can be extremely handy, as well as causing yourself far more hassle maintaining
your "blockade against evil", may not actually be doing yourself any favour and that there are far better ways
to handle these sort of situations.

Sure, yes you CAN keep your boot partion write protected and you can do it WITHOUT the loss of functionality,
it just requires you put a little thought into it first, here are some other options that you might consider;

) Move your ENVARC: to a dedicated partition, A volume called ENVARC will override the deferred assignment.
And yes, you can stop the icon from showing up on workbench, use workbench prefs and hide the image.
This way you can backup just the ENVARC: partition somewhere safe and not worry about a partition restoration
overwriting your system software (possibly updated versions), in the boot volume.

) If you don't want to move the entire ENVARC, and it's just the APPDIR cache which is bothering you,
you can simply use a TEMP partition or a location somewhere other than on the boot volume,
( I actually have one that I use to hold FTP files, downloaded emails, screengrabs and other general junk ),
you can use this to hold the AppDir directory contents instead of being in envarc, it will work perfectly well
replacing the appdir directory with a softlink that points to where you want to hold the appdir cache files
in a write enabled location.

EG: Here's how to move the standard setup. For this example, i'm using a partition called TEMP

Makedir TEMP:AppDir
Copy ENVARC:AppDir TEMP:AppDir
Rename envarc:appdir envarc:appdir-old
MakeLink SOFT link=envarc:appdir dir=temp:appdir

Now warm reboot....

Your boot volume can now stay write protected and your APPDIR: also works. If you moved the whole ENVARC,
then your prefs can now also be adjusted anytime too.

[nbache]

Personally, I've never felt the need to write-protect any system volume.

In the (extremely rare - even though I'm a beta tester) case of a booting problem after an update or the installation of a new program, I just boot from a fallback system (normally another boot partition, or worst case - like on the A12k where it's harder to select a boot volume during start - the CD). Then I look at my backup and determine what has caused the problem, and restore that. Or even restore the whole volume.

Having to do that once every couple of years (or something like that) is by far outweighed by not having to worry about locking and unlocking and getting errors because of the locking etc.

Just my 2 øre ...

Best regards,

Niels

[xenic]

MakeLink SOFT link=envarc:appdir dir=temp:appdir

I think that will only work if you are booting from an FFS partition. If you are booting from an SFS partition, copying files to a directory link on a locked SFS partition will result in a "Volume System is write-protected" requester and the copy will not succeed. Unless the AmigaDOS APPDIR: code can work around that SFS behavior, I don't think the link will help. I assume that you have both FFS and SFS partitions for testing so try this:

1. Create a directory link on an FFS partition to a directory on an non-writeprotected partition and lock the FFS partition.
2. Create a directory link on an SFS partition to a directory on an non-writeprotected partition and lock the SFS partition.
3. Try copying a file to both directory links.

I think you'll find that the copy to the directory link on FFS works but the copy to the directory on the SFS partition does not work. I would be glad to know if there is a way to make it work on an SFS partution because I had a lot of file and directory links back when I used an FFS system partition that now won't work with SFS.

[xenic]

Personally, I've never felt the need to write-protect any system volume.

Really? You've never run your system with a write-protected system volume as part of beta-testing. Assuming that the beta testers have a predefined list of performance tests to perform before a release, maybe you could add "operating with a write-protected system partition" to that list.

[nbache]

Personally, I've never felt the need to write-protect any system volume.

Really? You've never run your system with a write-protected system volume as part of beta-testing.

No, we have plenty to do testing that things work when not deliberately crippled.

Best regards,

Niels

[xenic]

No, we have plenty to do testing that things work when not deliberately crippled.

O.K. but I wouldn't consider write-protection crippling any more than I would consider it crippling to lock my doors before I go to bed at night. To each his own.