Hello Wilfred,

On 14 Feb 15 21:02, Wilfred van Velzen wrote to Nicholas Boel:

 WV> Ok, my opinion:

 WV> The processor can't know it's a typo. It can only see that the file to
 WV> be replaced doesn't exist on the receiving system. That's a legitimate
 WV> (local) situation and not an error in itself.

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

 WV> So the file + .tic can be passed on to the next system.

Sure. This way any typo will never be noticed, and people will end up with
multiple copies of files on their systems that could have been prevented in
the first place.

 WV> That the file already exists on the receiving system, and is not
 WV> replaced by the replace command, is a local problem, and is dealt with
 WV> by the local configuration. It can replace it anyway, it can rename 1
 WV> of the 2 files, it can put the new file in a bad area, etc...

I don't think that was the issue. The tosser is in fact setup to rename
files (in an incrementing fashion) if the file already exists. I just have
a feeling it was the original typo that stopped the processor from
continuing.

It was the fact that htick completely ignored any of this I thought may
want to be raised for discussion here. Basically allowing anything to get
by and cause a mess on your filesystem is now a "local" issue and
should be taken care of by any other means besides htick, got it!

Thanks for your feedback!

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20130910