No, that's not a commercial for a new food fetish. It's on the Amiga protection bits, or at least the protection bits how the (not-so) FastFileSystem defines it and the shell uses it.
Protection bits can be added or removed by the "protect" command, such as
7.SCSI:> protect ram:test s add
Sets the "s" protection bit. If you replace "add" by "remove", the bit is removed again.
In total, we have eight of them: hsparwed. The protection bits are partially interpreted by the shell, and partially by the filing system. Now, for the meaning, one by another:
If "d" is set, the file can be deleted, or "unlinked". If it is not set, "delete" on the file fails. This also implies that the file cannot be opened for overwriting, i.e. MODE_NEWFILE for Open fails if the bit is cleared. What it means for directories is pretty much up to the filing system. The current FFS interprets "d" as "the directory cannot be removed", but you can create files in it.
Before we go to "e", first "w": If it is not set, it means that the file cannot be written to. Or rather, almost. You can append to the file, but you cannot overwrite it, at least this is how the FFS currently interprets this, and I would probably call this a bug, because it means that you *can* write to a file, even though w is not set. The RAM: disk has the same issue. Interestingly, this probably changed with the FFS when it was re-implemented in assembler, from the BCPL OFS code.
For directories, "w" should probably imply that you cannot create files within. But it doesn't. Actually, I seem to remember early releases of the FFS did not store any flags for directories.
Regardless of "w", the files or directories can be deleted, so at least a bit of consistency.
"r" means that the file can be opened for reading. At least for files. For directories, one is tempted to say that it means that the directory contents cannot be read, but AmigaOs is not Linux, and consistency isn't its strength anyhow, so "r" doesn't mean anything for directories.
So does "e". Actually, "e" is not interpreted by the filing system at all. It is only interpreted by the shell. If the "e" bit is set, the shell considers a file a "binary executable", and loads it. Or rather, tries to. If that fails, an error is printed. Actually, if "e" and "s" are both set, then "s" takes priority and "e" is ignored.
Actually, the above is not entirely true: If "e" is set in a directory, then of course the shell does not try to execute the directory (how?). Instead, it ignores all other flags and implicitly changes the directory. Or rather, it loads the "CD" command from its built-in command list, and then passes execution to it.
The "rwed" flags are actually stored inverted in the file descriptor - if the bits are clear, they are printed as "set", and vice versa. Thus, if you don't do anything else with the file, the default is "rwed". Actually, not a very good default. "rwd" would have been better as it would have avoided that you try to execute your average text file. CBM at all its glory, once again.
So if what happens if "e" is not set? The shell checks whether the file can be opened by a data type, and if so, checkes whether the variable $VIEWER is set, and then passes control over to the command recorded in this variable. Thus, if $VIEWER is set, for example to "Multiview", you can view pictures, text, AmigaGuides... on the shell by simply typing their names. Ain't that cool?
The next bit is the "a" bit. It actually doesn't do much, except that it is cleared whenever the file is modified. Thus, one can set it by
7.SCSI:> protect foo a add
and whenever some program fiddles with "foo", the "a" bit goes away. Sounds useless? No, it isn't. It means that a backup program can skip over all those files whose "a" bit is set, as they haven't been touched since, and while it copies all programs back to another disk, it sets the "a" bit of all the files while it goes. Thus, it only copies what hasn't been modified - quite useful. Actually "SortCopy" (from Aminet) does just that.
The "s" is for "script". That is one of the flags only the shell cares about, and not the filing system. If it is set, the Shell tries to execute the file as a "script", regardless of the "e" bit. Thus, for that, it first checks the first two characters of the file. If they are "/*", the file is passed into AREXX. If they are ";!" or "#!", the script file is passed into the shell command that follows these two magic characters. That's what Linux does all the time, there "#!" is the magic "hash-bang". AmigaOs has it, too.
If neither "/*" nor "#!" nor ";!" is in the first line, then Amiga hands control over to "Execute". Which, as we know now, doesn't do anything special except messing with the file once again by substituting arguments in an completely inconsistent way, and then passing the result back into the shell for execution. Execute doesn't do the dirty job itself. It just creates the mess...
The "s" flag with all following flags are relatively new. The BCPL shell did not have them, and they came in relatively late.
"p" is for "pure". Which actually means not as much as one may think. It was an invention of the "AmigaDos Replacement Project" we've already heard about before: The idea was nice: Why do we have to load commands from the disk everytime again when we need them? So instead, if a command does not change its executable, its data section, and is re-entrant - can be called from itself and by several tasks at once - its code can simply be kept in memory, instead of requiring to load it from disk to memory every time again.
"ARP" had a mechanism for that: The file was checksummed, and if the checksum did not match, it was thrown out the next time. Of course, all that was too much for CBM, so the checksum went away. Instead, it is just a promise. If "p" is set, the command makes the promise "I hereby swear that I will not modify my data and by code. And if I do, I may crash next time". Good job, that's a great stable interface.
Hence, if "p" is set, you can load the command into the dos resident list (more on this later), and the Shell finds it there, and executes it from there rather than loading it from disk. And if "p" is not set, you can set it with "protect" nevertheless and try what happens if you make it resident... Errr, better don't. Only the program author can know that, and hence may set "p". And if it is not set, you better keep your hands off and don't make it resident.
This is how one can make the startup-sequence a bit faster, namely by moving often-used commands resident:
resident C:assign
resident C:copy
So they are not loaded over and over again. And actually, there is an even better way how to do that, without "resident":
Which brings us to the last bit, often misunderstood: "h". Some programs read it as "hidden" and don't list directory entries that have this bit set. That's just wrong, folks. "h" is not for "hidden", "h" is for "hold". What that means is the following:
If a file has the "h", "p" and "e" bits set, so it promises to be pure, and can be executed, then the next time the shell loads the command, it makes it resident all by itself. Thus, the above lines can be avoided in the startup-sequence simply by setting the "h" bit for all those commands you want to keep in memory anyhow, and you planned to make resident, except that you don't need a resident command anymore.
Unfortunately, due to size constraints, this nice feature was "thrown out" of the V40 shell in last minute, so the Os 3.1 shell does not support it. The 3.9 version does, as there is no ROM size constraint, and "h" really stands for "hold".