Hello mark,

On 15 Feb 15 10:59, mark lewis wrote to Nicholas Boel:

 NB>> The I can only be led to think that the processor that actually
 NB>> stopped this assumed the comma was a bad filename. With that, I
 NB>> can pass along the information to the other developer to allow
 NB>> for a comma in the filename, since it's allowed on both Linux and
 NB>> Windows.

 ml> just remember that it breaks on DOS and when passing to DOS machines,
 ml> certain additional steps must be taken... i remember when there was
 ml> work being done for transferring LFNs where the system had to choose
 ml> which name format to send to which remote system... 8.3 for those that
 ml> could not handle LFNs and LFNs for those that could... i'd have to dig
 ml> for the specifics as it was many years back and i don't recall if it
 ml> went mainstream or not but there were many systems operating with that
 ml> code... that's also one reason why most of the FDNs still use 8.3
 ml> names ;)

I'm not going to say much. Most of the above was somewhat sarcasm since
people like to avert from a problem in the software and blame your local
configuration and/or operating system.

IMO, the software that caught it and changed the .tic to .bad, while not
processing the file is working the way I would expect it to. It was because
htick processed it normally (not finding a I-BINKD,TXT so as not to replace
anything) that I mentioned something about it here.

If the developers want to treat it as "normal" (even though I've
*never* seen filenames on both Windows and Linux with a comma in use, even
though it may be allowed), and pass it on to potentially harm other
systems, that's completely up to them. :(

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20130910