Jeslint error

[roedygr]

I got this error on three files with batch validation:

[JSLint] An error occurred trying to run JSLint. Error: 2005052002: can't open error/message file "C:\Users\Roedy\AppData\Local\Temp\~cse_jslintmsg117815232.tmp"; GetLastError() returned 32: "The process cannot access the file because it is being used by another process."

When I validated them in the editor, they were ok.

I have JavaScript link checking turned off because I also have some Microsoft script in there as well which HTMLValidator thinks is JavaScript.

What's odd is the JavaScript in question occurs on nearly every page, not just these three. It is the javascript for Google translate and two google adsense ads.

[Albert Wiersch]

That's interesting. I am not sure why you would get that error but I suspect it could be an anti-virus or anti-malware program that is locking the file temporarily.

I have added some logic to the v11.0000 release version to wait and try the file a few more times before failing, thus the lock may be released and the file opened successfully on another try.

If you do not want any JavaScript checking, then you will also want to turn off the new JSLint checking in v11. However, JSLint may work better than JavaScript Lint so you may want to check that out first.

[roedygr]

Hmm. It might be Copernic, an local file indexer/search. I usually have it turned off to avoid conflicts. I might have left it running, since I have been using a lot recently to find and research acronyms. That would explain why it only complained about 3 files. They might have been ones I recently changed and Copernic then decided to re-index them. It would only hold onto them for a few tenths of a second.

On your end, coming back later after you have done others in the batch would have best odds of success.

I think also Vslick editor sometimes locks files you are editing/viewing.

Reiterating an old idea, It would be nice if you had a database of files you have previously validated successfully with the date and file size. When asked to batch validate, you can bypass I would guess 90% of the work by looking in your database and displaying the cache if the file has not changed since the the last verify. The net effect would be about a ten times speed up of the batch validator. The simple version just keeps successfully validated files. A fancy version would keep the errors from ones that failed too.

[Albert Wiersch]

Reiterating an old idea, It would be nice if you had a database of files you have previously validated successfully with the date and file size. When asked to batch validate, you can bypass I would guess 90% of the work by looking in your database and displaying the cache if the file has not changed since the the last verify. The net effect would be about a ten times speed up of the batch validator. The simple version just keeps successfully validated files. A fancy version would keep the errors from ones that failed too.

That's an interesting suggestion but might get confusing and complicated... like what if the options changed? To do it right, this may require saving all the options with the results, then the current options would have to be compared to the saved options as well as the file size & time to see if anything has changed. I think it could be done, but it sounds like it could introduce other problems & complexities. I suspect there may be better solutions, like keeping a list of targets that aren't checked in a target list file, then the user could manage those targets & a Batch Wizard run could add targets to the list if they have no errors or warnings. I'd have to think about this more... perhaps for a future major new release, given enough time.

[MikeGale]

While reading this it occurred to me that the following might be part of a solution.

The batch file is XML, of a style that can be thought of as a database.

<target flags="1069547540" target="http://***">
<fiec flags="0" agent="Mozilla***" acceptlanguage="en" url="http://***" />
</target>

The targets don't have ID's (which makes a separate file harder to do) but the structure could be enhanced to do what is proposed here.

Either adding attributes to fiec or adding another element

<target flags="1069547540" target="http://***">
<fiec flags="0" agent="Mozilla***" acceptlanguage="en" url="http://***" />
<lastrun when="<datetime>" status="no-problems" filetimestamp="<datetime>" filesize="<KB>" dontcheck="true/false" />
</target>

If the additional structure were optional, existing files would just work. It also gives a way to manually intervene (alter the dontcheck flag is you really need to).

Just a brain-storming thought. I haven't thought through this one in detail!