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 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]> 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]> > 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. > > >
