That, (other systems), is a great example of yet another unpredicted yet valid situation.
What if one reads the description on the tin for the tpdd emulator, which says it emulates a tpdd... So they try to use it with a Brother sewing machine. Is it harmless to upper-case the filenames or modify the contents of files in that case? Maybe the sewing machine doesn't happen to use files named *.DO, or maybe it does, or maybe the names can be anything including .DO with no special meaning? Someone also mentioned upper-casing the filenames. Since when is that an automatic safe assumption? I can create filenames with lower case letters perfectly fine on a real machine. All of the situations mentions where the munging is supposedly helpful, are what's called shims, and the only reason a shim is needed is because some other program did something bad, and now you have to do something bad as well, in the opposite direction, just to get the final result that is the same as if neither thing had done something bad, IE even the shim admirer is working towards un-munging data that someone else munged, and therefore admits the goal of not munging data! The text editor example is just like ftp. Ancient text editors did that (and really crappy current ones), like ancient ftp. Since then, the idea has been recognized as more harmful than helpful, and nobody does it any more. ftp clients still do it because they are just adhering to the original standard. But the standard is old, and newer standards don't do it. http does not do it. (http clients & servers may negotiate things like gzip compression in-flight, but the data going in one end comes out the other end faithfully) That behavior of some old text editors to re-write line-endings or append an eof, exists, but is also recognized as a *bad* thing, which is why anyone doing any kind of actual work with tex files, not just programmers but anything like examining EDI transactions or literally anything, are told not to use notepad.exe, but to install notepad++ or any "prgrammer" editor. none of vi, vim, emacs etc do such things, etc. Why not? Is it because in 40 years no one has gotten around to adding this clearly helpful feature? Wherever you feel a need for a shim, it's a necessity to correct for someone/something else's undesireable behavior, not a supporting argument for doing the same thing some more. It's bad enough that we do some other smoke & mirrors with special filenames in order to implement subdirectory support. I don't remember off-hand if foo.<> is a possible legal filename that a M100 could create or not. It's a very useful feature to be able to have subdirectories, but even this could theoretically screw something up that was otherwise legal. For instance, is it legal/possible for a program to create a file named foo.<> which is just used internally by the program, never loaded in TEXT or TELCOM etc? If so, next question can that file be saved & restored to a real disk the same as any other file? If so, then is that application simply broken and unusable with any tpdd emulators that implement TS-DOS directories? Are there any safe assumptions about filenames like that wrt other clients like sewing machines and synthesizers? It's such a useful feature, and it's been a de rigueur standard for so long by now that even *I* would not suggest that any sane tpdd emulator should remove it. :) I don't remember from last time I was looking, maybe that theoretical possibility is actually allowed for by the tpdd server recognizing, or failing to, that the client supports or expects the feature, and maybe NOT treating those filenames specially, or sending filenames like that to show directories, if the client is not TS-DOS? -- bkw On Wed, Feb 13, 2019 at 4:53 PM Kevin Becker <[email protected]> wrote: > An option to not crash the system but also account for some of the > scenarios Brian suggested would be to create a log file that details any > file manipulations that happen during a transfer. That could be useful to > some developer trying to write a TPDD emulator for some other platform in > the future. > > On Feb 13, 2019, at 4:30 PM, Gary Weber <[email protected]> wrote: > > > Good point, Mike. I actually think I support the opt-out feature, just > as long as the name of the switch on the LaddieAlpha.exe command line is > --allow_file_system_corruption > > > On Wed, Feb 13, 2019 at 2:20 PM Mike Stein <[email protected]> wrote: > >> Give up, John; just add a -EOF CLI option as requested and let the user >> guess which one will crash the system, or better yet a checkbox: >> >> "Crash system after loading (Y/N)?" >> >> Most ridiculous argument I've read in a long time; why burden an >> inexperienced user with a choice that he/she might not understand when one >> of the two options will crash the system? >> >> A good program IMO does its job with as little confusion and/or risk for >> the user as possible, regardless of some irrelevant CS101 "principle." >> >> Maybe just mentioning in the documentation that an inappropriate CTL-Z >> will be stripped and the extension changed if necessary will satisfy the >> zealots... >> >> Sheesh! >> >> ----- Original Message ----- >> *From:* John R. Hogerhuis <[email protected]> >> *To:* [email protected] >> *Sent:* Wednesday, February 13, 2019 2:14 AM >> *Subject:* Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version) >> >> "That places the obligation on the wrong party." >> >> It's not a legal issue. It's just functionality. >> >> Arguing on other turf (FTP, or checksum algorithms, etc) is to totally >> ignore the issue. >> >> But really, you're arguing on the basis of principle that I agree with in >> principle, but in real life an engineer weighs the issues and can set ANY >> principle aside. >> Yes my decision will violate your assumptions in a hypothetical scenario. >> I guess. >> >> That's what I did here, I set a principle aside, because there is zero, >> or really, negative, value in inloading a character that crashes the >> machine. >> >> The exception to the rule serves the greater good, such as it is with our >> little hobby. But I make decisions just like this in work, and it is part >> of what makes me a good engineer. >> >> -- John. >> >> > > -- > Gary Weber > [email protected] > > > -- bkw
