Is asterisk the only "bad" character that can ever appear in a filename produced by a M100?
The standard encoding was for 2 reasons: 1: Handle any possible kind of unwanted data, not just the single thing you percieve today. 2: When you encounter the munged file by itself, it has meaning and you know what to do with it, even if you aren't the one who created it and don't know anything about the obscure translation some obscure program did to the file. But now I see a 3rd maybe even more important consideration, that urlencodeing or any multi-byte encoding doesn't help: Ideally, the munged file should be usable by any other tpdd server or client. I don't use just one tpdd software, and I would resent any that made it difficult to move files around and switch between software and platforms. If I save a file in tpdd-foo and then can't read the in tpdd-bar, because tpdd-foo did something to the file that only tpdd-foo knows how to undo, then I stop using tpdd-foo, or use it and hate it if I can't avoid using it. This makes urlencoding kind of both ok and not ok. A urlencoded filename is unusable by any other tpdd server, (or client, you couldn't use the python client to put the file onto a real disk either for instance), because the length can exceed 6 bytes. That's a demerit. BUT, since the munging was in the form of a common standard, you at least know how to un-munge the filename, even if you are your grandkid or some random internet searcher who finds the files by themselves without knowing the software that created it. That's a merit. If there is only one bad character that a m100 might produce, and we can replace it with something else which is also a legal m100 filename character, then you also have one plus and one minus. Plus: save the file in mcomm, copyit somewhere, and still be able to read the file in some other tpdd server. The other tppd won't know to un-munge, but the munged filename is legal on m100 too, so at least it's usable. Minus: I allows the possibility of name collision. Assuming a carat is a legal m100 filename char, or assuming we use something else that is, What if you have both foo*.ba and foo^.ba on the m100? If there is only one bad character and we replace it with sonething which us NOT legal in a filename on a m100, then we have the original problem that the file becomes unusable by other tpdds and only tpdd-foo (or the person who used tpdd-foo to save the file) knows how to unmunge it. Well, it was worth trying, but after trying real hard, I see no answer that's any better than any other, so nevermind! Leaving the asterisk is technically possible in all major platforms. It's a valid character in a filename. But I agree with not doing that. Munging causes some small issues, but not munging would be worse. -- bkw On Jan 3, 2018 8:46 PM, "Kurt McCullum" <[email protected]> wrote: > Since the Android version works as is by translating CUST*S.DO -> > CUST~S.DO I'll change the Windows version to match. The tilde seems to be a > good character to replace with without causing problem. Also, thanks for > the bug tip about the append problem. I'll tweak that while I'm in there as > well. > > Kurt > > -----Original Message----- > From: M100 [mailto:[email protected]] On Behalf Of Jim > Anderson > Sent: Wednesday, January 03, 2018 5:10 PM > To: [email protected] > Subject: Re: [M100] mcomm difficulties > > > -----Original Message----- > > > > Suggestion, before too many people start relying on it, replace the > > random/arbitrary substitution with some standard encoding like > > urlencoding. > > So, translate model T file names like CUST*S.DO -> CUST%2AS.DO in the TPDD > folder, and vice versa? I wonder whether it's more likely to encounter > model T files with legit % signs in their names than with legit ^ signs in > their names... > > What would be really great would be if there is some character the model T > disallows in filenames but which unix and windows do allow, then translate > the asterisk to that character. :) > > > > > > > > jim > >
