The closest thing to a perfect solution... that just works... is for the disk service to present the proper extension instead of the incorrect one. That's what Laddiealpha does. It peeks at beginning of the file to see if it's a binary file and automatically presents a correct extension to TSDOS. Whether the user knows how to load that file is a separate concern. But I figure people will simply ask on list.
Other ways to go: Do not present the file at all in the directory if a mismatch is detected. The user will see it as a mystery but they can read their documentation or ask on list and the mystery will be resolved. Another idea would be to rename it in some way to be clearly bad like "FILE.><" So it's not just missing. Present the filename as is. But when at the protocol level the file is opened or on the first read then an error is returned based on inspection of the file. TSDOS or whatever will report the error and the user may figure it out or they will ask on list. I haven't explored this but theoretically it should be feasible. Embed a tokenizer in the file server to automatically make the content match the extension. This won't always work. And it would have to be laptop model aware since 100 vs NEC tokens. -- John.
