Brian,
It certainly does create an issue if you name a file with a carat and then reload it. The new filename with have an asterisk on the m100. And as you point out, there is still a problem with the m100 allowing invalid characters. The only reason for this fix is because T-Base, an existing model-t product, uses asterisks in its filenames. To use T-Base with a tpdd emulator, its files have to be dealt with. Either by remembering to re-name them before saving and then again when reloading, or by having the TPDD emulator do it for you. Something to ponder. How many people use those invalid characters in filenames? You can create a test file that does, but in normal usage I think this is a non-issue. Kurt From: M100 [mailto:[email protected]] On Behalf Of Brian White Sent: Friday, January 05, 2018 5:06 AM To: [email protected] Subject: Re: [M100] mcomm difficulties This just leaves two questions: The carat is an ordinary valid character in a M100 filename. So how does mcomm avoid renaming my file which I named with a carat in the first place, and turning it into an asterisk when loaded back on to a m100? And of course there is the name collision problem mentioned already. Since I can have both foo^.ba and foo*.ba on the m100 at the same time, what happens when I save them in mcomm? One overwrites the other and one is lost? Until a proper answer is figured out, maybe just leaving the original filenames untouched is better. It's not *that* much of a problem since they always were valid characters and so every filename-handling utility already has to handle them anyway. Or maybe the urlencoding idea isn't so bad after all because all the other tpdd servers and clients that anyone is still using, have source available and can be updated to all agree on some standard like that. I just tested and sure enough other "bad" characters are perfectly easy to create on the M100. I just did SAVE"TEST/X and now I have a TEST/X.BA <http://X.BA> You'd have to do *something* with that no matter what. Either munge it or refuse to save it at all. If munging it by urlencoding means some other tpdd can't use it, how is that any worse than if the same file just couldn't be saved in the first place. The other tpdd couldn't use it then either. -- bkw On Jan 4, 2018 5:07 PM, "Kurt McCullum" <[email protected] <mailto:[email protected]> > wrote: It hasn't been a problem mainly due to the m100 user not naming their files with asterisks in it. Unfortunately, T-Base does so I made the tweak for one character. the "*" ---> "^". This is a simple fix and it works. As Brian pointed out, any other TPDD server can still read the file. Worse case is you have to rename it. Kurt On Thursday, January 4, 2018 2:00 PM, John R. Hogerhuis <[email protected] <mailto:[email protected]> > wrote: Well, it looks like Windows uses Unicode for filenames in NTFS. FAT uses the OEM character set. The special characters are '\', '/', '.', '?', and '*' It wouldn't be a big deal to map those to/from other characters in LaddieAlpha since I already maintain a filename mapping table for various reasons (fix for the BA/DO issue, filename length, and various text file extensions -> DO). As to character sets... Model T extended characters could be mapped to / from their Unicode or OEM equivalents. The Unicode mappings were created in part for the HTERM project. We don't have mappings for the OEM character sets. It just hadn't been brought to my attention that this was a problem :-) -- John.
