Topic on Project:Support desk

T110630: mediawiki.log.js is quarantined by Comodo anti-virus, unpredictable failures result

Greetings,

I have recently downloaded and configured (basic), via a your tutorial, the mediawiki application. It install successfully. Now I am trying to back-up the mediawiki main folder to an external hard drive, but it keeps failing with the error:

---

Error copying file or folder:

Cannot copy mediawiki.log access is denied

Make sure the disk is not full or write-protected

and that the file is not currently in use.

---

I'm using Win XP SP3. The only file that won't copy is mediawiki.log.js (there is no "mediawiki.log" file).

Here is what I have checked/tried already:

   1) Space is not the issue because there is over 50GB available on the destination disk.

   2) Changed the main mediawiki folder in my www directory (WAMP) to have "read-only" unchecked.  Applied this to all subfolders.
       * Strangely, the folder keeps setting permissions back to show that some files are not read-only (solid green box as opposed to the green checkmark).  Not sure if it makes a difference or not, but thought I'd mention it.

   3) Sharing tab: I set it to share the folder & give everyone all permissions.

   4) Security: Everyone already has all permissions as default.

   5) Disable real-time protection on my Antivirus (Microsoft Security Essentials)

   6) Tried since copying the file (mediawiki.log.js) or its parent folder did not work in Windows, I also tried from the command line, which failed as well.  All other files in the folder copy fine.

Am I the first person to report this error? I'm frustrated now because all the tricks i know didn't work, which is why I'm seeking help. My supposition is that the mediawiki developers "locked" that file for security reasons, assuming it would be a security liability on a production site. Am I right? If so, I need to know how to unlock it so I can do what I want with it on my local personal server. If not, please advise on how to proceed because I've done everything I can think of already.

Your help is greatly appreciated.

Regards,

-CodeSlayer2010

Hi!

The file you mention is resources/mediawiki/mediawiki.log.js, right?

There should be nothing special with this file. I am also running some MediaWiki installations and I also do regular backups, but I never had this problem.

Maybe something is broken with the file permissions? Try deleting it and replacing it by a new copy. Maybe the problem is solved after you restarted your PC?

Mediawiki 1.20.2 / PHP 5.4.7 / MySQL 5.0.51 on our apache we have a intranet and an internal WIKI running. A few times a day the intranet en the wiki is hanging. We have to stop and start the apache (2.4). Investigation shows that at those moments the port 80 is not available. We did some testing. Seems like when we remove WIKI from the apache and only run intranet, there is no problem. when we add wiki back to the apache the problem occurs again. Any idea what the problem may be?

Do your logs show anything when this happens? Have you tried enabling the debug log?

@CodeSlayer2010 There is nothing sensitive or special about mediawiki.log. There is no lock of any kind on that directory or the files within.

If you download a fresh copy of MediaWiki, does it work with that? I suspect something or someone might have messed with your mediawiki install and messed up something on that directory (at random / by accident).

@Krinkle & @88.130.65.121: Thanks for that info and suggestions. Since you say that there is nothing special about mediawiki.log (and yes 88.130.65.121 I mean resources/mediawiki/mediawiki.log.js :), I'll have to conclude that there must be a hardware issue on my drive, perhaps bad sector?

If I download a new copy of mediawiki.log.js, is there anything custom about it? Will it erase my data? It is just the script that generates the actual log, so it should be safe to overwrite, correct?

Thanks!

No, this file just comes with MediaWiki and has nothing custom.

Yes, you can download your MediaWiki version again, extract that file out of the newly downloaded package and overwrite your old file with it. It will not change anything with any data in your wiki (which for the most part is stored in the database).

I dont't know, if what you describe can be caused by bad sectors; in that case I would expect that you can no longer read the file (e.g. when you open it in a text editor that does not work or you only see garbage).

I don't know what causes your problem. I once had the case that files were extracted in a folder and extracting them seemed to work (at least it did not give an error and the files were extracted). However, a few of the deepest files finally had a path and file name, which was longer then should be possible. Windows was unable to access the files. Through the tar tool, which I used to extract them I could finally remove them again... Maybe something like that is your problem?

Possibly relevant: a year later, my antivirus has automatically quarantined mediawiki.log.js from mediawiki-1.22.2 for apparently containing the "Heur.Dual.Extensions" malware. It plucked the file out of the directory and quarantined it.

"Heur.Dual.Extensions" sounds like it's only a heuristic alarm; the antivirus has not actually found something it knows in the file, it only thinks it might be suspicious. If the file is a true copy of what comes with the MediaWiki package, I think this is a false positive and you should inform your antivirus provider so that they can check and then maybe fix their definitions.

Good point, I didn't realise that "Heur" was an abbreviation, and the file clearly has two extensions, "log" and "js"! Disappointed that my antivirus (Comodo) wasn't clearer about what it was doing there.

Maybe the antivirus program is the source of the problems you're having, if it blocks access to that file while you want to move it or when apache access it to serve the file to clients.

Ciencia, if you had read before posting you would have seen that we already know that.

How did you came to that conclusion?

Do you really want to discuss that now? How about to instead start doing something useful?

Excuse me, but it wasn't me who started posting useless replies here. Looks like you don't like the game you started.

Just that you get me right: I don't have any problem with you believing it was not the antivirus; you can also believe in Allah, Christ or the Flying Spaghetti Monster. If you have evident proof that it cannot have been the antivirus, I am happy to hear. But until then...

Maybe Comodo Antivirus has options to tun heuristics to a lower level or maybe completely off. Maybe it also offers a possibility to set up exclusions, which should not be checked. However, the fact that this heuristic rule is ther is generally useful: In older versions of Windows (or also in current ones?) file extensions are by default hidden. That way especially unexperienced users can be tricked into executing a file, which looks like it was e.g. called "Winner.txt" while it in fact is named "Winner.txt.exe". So generally this check is helpful, but not in this case.

This just happened to @VEckl (WMF) , Comodo anti-virus quarantined mediawiki.log.js because it looks like an executable file trying to trick the user into executing JavaScript by masquerading as a text-only "mediawiki.log" file. It seems that if your MediaWiki installation works, you can get by without this file, but if there are any other problems with your code, MediaWiki can't report them in the browser because this file is missing :-)

I filed T110630, "mediawiki.log.js is quarantined by Comodo anti-virus, unpredictable failures result"