Not even Microsoft can handle an ä in the path! The ssh implementation failed to copy a file to the server because there was a directory called Präsenzen in the path.
Note: I did not specify the path, just the local filename without path. And ssh told me: file not found...
On July 1, 2017 my backup to an external USB hard disk aborted unexpectedly. When I tried to restart it, the batch file complained that it could not find robocopy any more!
Suprised, I restarted the PC and tried again: same error...
robocopy was nowhere to be found, but all the other programs seemed untouched. Therefore I concluded that it was probably not a trojan which had deleted the program. When I copied it from another disk, the backup ran to completion.
It turned out that the culprit was Kaspersky Anti-Virus! It had classified the program as PDM:Trojan.Win32.Generic and quarantined it in the middle of the backup process.
If you ask me, an Anti-Virus program that kills a backup is worse than a virus!!
By the way: it is the original robocopy.exe shipped by Microsoft, and not a corrupted or infected version.
We spent several hours to find the cause of "no protocol: schule.dtd" in editix. After looking through the Editix manual (no hint), searching on the internet (no success), we tried to find the string "no protocol:" in google.
That way we found a few pages which pointed to an error in the XML parser of Java, which occurs when there are spaces in the file name. Of course, we had no spaces in the file name, therefore we tried other searches but found nothing
Just as we were about to give up, we came back to the page with the file name. This time we looked at the full path and found the string "\käslin\" to be part of the path. We changed that to "\kaeslin\" and it worked !
We don't know who is responsible for this bug, but the problem reports tend to point to Java. Hey, this is 2011, Java strings are Unicode and that damn thing can't read a DTD because of an ä in a path :-(
We have found that JEdit also suffers from this bug, but they don't even bother to display an error message. This behaviour makes it impossible to find the cause ;-(
But the JEdit support is really good. When we posted the error to the bug tracker, they looked into the matter and recommended an upgrade. The upgrade solved the problem.
Yes, we are still using Delphi 6.0, because we have some programs to maintain...
If you ever encounter an access violation in coreide60.dll (Read of address 00000000), and can't save certain files, try this:
This fixed the problem for us, and it might work for you, too.
It seems that delphi is caching some information about the project and that this cache can get out of sync.