Ok but… why? Does anyone have enough knowledge to speculate why that bit would prevent you from reading the code?
> In the editor, I could also clearly see the text of the BASIC source code for all the programs. It was there, not encrypted.
Also “Never underestimate a time-rich, money poor kid”
Or if it was some unreadable ASCII character, maybe it worked like an EOF in the editor? But the fact that he switched it from an F to an E gives me no clues. This stuff is unfortunately before my time, I'm sad I never got to play around with stuff like this in my youth.
However, technically, switching an 'E' for an 'F' is flipping *two* bits :/
On RISC OS, as that page says, a BASIC file has type FFB. I remember a plain text file had type FFF.
[1] https://www.kernel.org/doc/html/latest/filesystems/adfs.html
[2] https://docs.huihoo.com/doxygen/linux/kernel/3.7/adfs_8h_sou...
"
The RDOS file system provided means for protecting files by setting attributes. Because RDOS, not being a multi-user system, had no notion of file ownership, attributes applied to all programs that accessed a file. The sense of the attribute bits was, in most cases, the opposite of that in Unix; if the bit was set, the operation was prohibited. Files were by default created with all attribute bits cleared, permitting all operations. The attribute bits, as identified by the letters used to identify them in a file listing, were:
'R': prohibited reading
'W': prohibited writing
'P': "permanent file"; prohibited renaming or deleting the file
'S': identified a "save" file, that is, one that contains an executable program.
'N': prohibited symbolic links from linking to this file
'A': attributed protected; prohibited any further changes to the file's attributes. (A file that had both P and A set became un-deletable, except by reformatting the disk.)
'I': Prohibited reading or writing by means other than direct block I/O. (This was removed from later versions of RDOS.)
'?' and '&': User-defined attributes, ignored by RDOS