Well, the mechanism is there, it's not that hard if you think about it, the server needs a -->DIRECTORY<-- called ENVAR:AppDir to be able to create the cache files inside it, if the server can't find a directory of that name on bootup then the server process simply exits politely.
I tried and it doesn't work: in fact, the ENVARC:AppDir gets created automatically (and then used, of course). I solved the "problem" by replacing it with a dummy file.
Quote:
If you havn't started a program even once in 6 months, it's probably safe to say that you don't use it anymore.
But if I still have the program in place, it even more probably means I think I will/may have use for it the future. I still think that removing valid entries is not wise, as that can lead to annoying "program not found" errors.
Quote:
As far as entries with a bad path, they get flushed at every amiga day number that is a modulus of 31.
Ah, OK, that's already something.
Edited by saimo on 2010/1/19 17:06:20 Edited by saimo on 2010/1/19 17:06:56
As it seems, it is important that you devs step in and explain things. Amigans tend to be suspicious of new features, and the fact that they often refuse good concepts probably stems from a lack of information or misunderstanding.
I know that "power to the people" is the key phrase for Amiga, but the fact that users are replacing WBStartup prefs with the old WBStartup drawer, or making scripts to wipe the APPDIR, is worrying. They are creating custom-modified setups that will be prone to bugs, difficult to update, and hard to debug for. They wouldn't do it if they knew how the features work and what they are for. And if the developer team were more strict on people who modify their OS in such ways.
Good grief, why exactly would you want to disable APPDIR: it would have to be the single most usefull DOS feature since PROGDIR: and CURRDIR: were created.
1. Because I keep my system partition write-protected with the lock command and no filenames will be stored anyway. 2. Because duplicate command or program names will cause problems at some point. Examples: Prefs/OpenURL & C:OpenURL, SDK:Local/C/cut & C:cut, ImageMajick/bin/compare & C:compare(personal utility). Some programs have utility programs located in their home directory that have names duplicated elsewhere in the system. 3. Due to items 1 & 2 above you will never be sure which commands or programs will be started with an APPDIR:filename command.
Give us some prefs to control where the filenames are stored, control what filenames can be stored there (i.e to blacklist some commands that have duplicated names like SDK:Local/C/cut and C:cut) and disable the system entirely if problems arise.
I solved the "problem" by replacing it with a softlink pointing to a non-existent directory.
It might be more system friendly to write-protect the AppDir directory by clearing the "write bit" with the C:protect command or Dopus4 protect button. That way the system will be able to copy the ENVARC:AppDir (although empty) directory to ENV: at boot time instead of encountering an invalid link. Just be sure to delete the AppDir files before write-protecting it.
How do programs store their settings when they need to write to ENVARC: and your system partition cannot be written to?
I have installed "Lock" & "Unlock" menu items in my WorkBench menus that call scripts to lock and unlock the partition. You can also add similar commands to AmiDock or hot keys with FKey. If a program tries to write something to my system partition that I didn't tell it to, I can unlock the partition with the "UnLock" menu and hit "Retry" in the write-protected requester. If I don't want something written to my system partition I select "Cancel" in the requester. If I want to save something to my system partition, I click the "Unlock" menu prior to saving and click "Lock" menu when the save is complete. I've also set up "Lock" & "Unock" buttons in Dopus4 that call the same scripts. The scripts also set an environmental variable to keep track of whether the system is locked or not. It would be nice if I had a little docky to display the lock status of my system but I haven't thothered yet. I've been running my system this way since the lock command appear in AmigaOS. By the way, it's not just old 68k programs on Aminet that will overwrite system files with older ones when you install them. Some programs like SVGTools (overwrites C:fc-cache with an older version) on OS4Depot will do it too.
@xenic A better solution might be to have a backup of your Workbench/OS partition, and to periodically compare files to see what has changed. If you dislike any changed, then you revert them, otherwise you save those changes to the backup.
Why not let envarc:appdir be a softlink to t: or whatever... NIL: would be fine with me, I find the entire concept is totally retarted, something I'd expect to find on aminet as the result of some whack idea someone wanted to test out, not something that suddenly is mandatory in an update to a minor release of the OS.
It might be more system friendly to write-protect the AppDir directory by clearing the "write bit" with the C:protect command or Dopus4 protect button. That way the system will be able to copy the ENVARC:AppDir (although empty) directory to ENV: at boot time instead of encountering an invalid link. Just be sure to delete the AppDir files before write-protecting it.
I had tried that, but to no avail: entries kept on being stored anyway. Moreover, as colinw informed us, if AppDir is not a valid directory, the server quits - and I definitely want a useless process less (sorry for the horrible pun) running
How do programs store their settings when they need to write to ENVARC: and your system partition cannot be written to?
This is only supposed to happen when you hit the "save" button, what has changed?
This is not true. With the introduction of application.library some five years ago, apps registered with the REGAPP_SavePrefs tag can have their settings stored in ENV(ARC): automatically at exit time, ie. without the user hitting a Save Prefs button.
By write-protecting your system partition, you also prevent the system or applications from storing environmental variables.
I, for one, appreciate APPDIR:. It's a work of genius, and avoids needing loads of search paths for commands in directories I hardly ever run. I can't remember where I put MemGuard, it isn't in my path... use APPDIR:MemGuard. Easy.
It also gives a guaranteed method of finding install paths without creating them manually.
You can use APPDIR: in scripts rather than the full path to a command and it will work, on anybody's computer, or if the command is moved.
It's the single best new feature I've seen in AmigaOS since env-handler was integrated. This is exactly the innovative types of features we need to keep AmigaOS ahead of other OS in certain areas.
Yeah, i like it a lot too. For now just does not remember where my Snoopy is placed, in work:debug, or in work:debug/snoopy, or somethere else, so, appdir:snoopy - cool :)
- I haven't take care enough but when installing AOS4.1.1, and if the user allready have 4.1 installed, a good point is to pass the resolution setting (during the install).
NOTE: I have installed AOS4.1.1 over 4.1 and no problems so far (boot fine and verry stable untill now (installed 1,5 hours ago).
Like that I have all libs, locale, MUI addons,... allready installed with AOS4.1 (but there are some files and settings finally removed (for example my MUI settings and no reasons because no changes on MUI).
A1200+Mediator+VooDoo3+060/50+96mo+IIYAMA 17"+CD,CDRW,ZIP SCSI-KIT SAM440EP on Mapower 3000+AOS4.1
This is not true. With the introduction of application.library some five years ago, apps registered with the REGAPP_SavePrefs tag can have their settings stored in ENV(ARC): automatically at exit time, ie. without the user hitting a Save Prefs button.
I see :(
I only have 4.0 that I rarely boot, all these "improvements" are for the worse in my view, obviously OS4.x is not for me. :(
It's the single best new feature I've seen in AmigaOS since env-handler was integrated. This is exactly the innovative types of features we need to keep AmigaOS ahead of other OS in certain areas.
I dont see innovation here, it's more or less the same type of application history as found in numerous OSes (typicalled used for generating "recently launched apps" etc), and there's nothing Amiga about it.
Yes, OS4.x is apparently developed by a clueless bunch of village idiots who have no idea about innovation. All the new features they've introduced are retarded and un-Amigan. They should have asked you before they started with the work.
Man, what a storm in a tea-cup one little feature is generating. I humbly suggest that people try out this feature first, before claiming that it's going to screw up X, Y, and Z. Secondly, I wonder why people are frantically trying to disable something that they're probably not using directly themselves. No-one's forcing you to start apps via APPDIR:, you can continue to double-click on icons as you like.
I don't understand how this is un-Amiga-like either, it's a feature to make some things easier, and it doesn't get in the way of those who don't need it.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
