ryerman

Member
  • Content Count

    30
  • Joined

  • Last visited

Community Reputation

0 Neutral

About ryerman

  • Rank
    Member

Profile Information

  • Gender
    Not Telling
  • Location
    Canada
  1. Correct. The message in the command window indicated an item was removed, but the ZIP archive was still in its original location. Here's what I did: 1. make sure the Quarantine list in EEK is empty 2. download eicar_com.zip to C:\Downloads (or any convenient location) 3. execute this command with admin rights: a2cmd /a /q /f="C:\Downloads" 4. observe successful completion of scan, including statement that 1 item was removed 5. open the download location and observe that eicar_com.zip is still there 6. open the Quarantine folder and observe an .EQF file -Windows Explore says it is 26 bytes which is very small compared to 4 or 5 KB, the size of the EQF file that results when removing the unzipped eicar file 7. open EEK (a2emergencykit.exe) and click the Quarantine tab 8. observe the listed item, which is incompletely and/or unintelligibly described 9. select the item and click "Restore" 10. observe the "unable to restore to original location" message and choose to restore to another location 11. EEK crashes when trying to save to the new location Maybe you can confirm that the ZIP archive is not removed properly? Thanks for your attention.
  2. Yes, once the service was installed, the /s switch allowed a2cmd.exe to scan without admin rights. Thanks for the suggestion. However, there may be a problem with the /quarantine switch. My preliminary testing revealed that the zipped EICAR test files are not quarantined properly, even though they are detected. Perhaps that is a topic for another thread, and I will wait for any response to the bug report. At least the scans now return the appropriate result codes. Thanks again.
  3. Some years ago, I began using my download manager to automatically scan all downloads with A2CMD.exe and the /f and /q switches. At the time, the EICAR test files were successfully detected and quarantined. I also checked the results code, knowing that it should be 0 or 1 for a successful scan. My tests showed that this all worked as I desired without invoking administrator rights. Now, no scan occurs. Neither 0 or 1 is returned as the result code. That is a big change and causes a problem for me. But I am getting confused because it seems that Emsisoft support staff are not in agreement on this issue. Here is Christian Peters: It seems as if he believes there is a problem. On the other hand, your explanation makes no mention of a problem or bug so I am left with the impression that you feel things are working as desired. Perhaps a resolution will come after somebody looks at the bug report that is to be submitted.
  4. On my system, if clean32.dll is version 1.0.0.173, the CLS runs without an elevated Command Prompt, which had been possible for years. Now that clean32.dll has been updated to ver 1.0.0.175, the CLS must be run from an elevated prompt. Hopefully, the developers will reinstate the original behaviour so that users will not need to explicitly use an elevated prompt for the CLS.
  5. You're welcome. I don't know when tracking cookies detection will be removed. As GT500 mentioned in post #35, Ghostery is an alternative. Ever since I installed Ghostery and DoNotTrackMe add-ons in Firefox, tracking cookies are rarely found by EEK scans.
  6. Emsisoft employee Christian Peters has verified that there is a problem with the latest version (1.0.0.175) of the Cleaning Engine (clean32.dll). It may be causing your problems. See http://support.emsisoft.com/topic/14233-emsisoft-cls-ver-81031-does-not-perform-scans/
  7. Thanks! I'll watch for an update that solves the problem.
  8. After further investigation, I may have found an explanation. I have a copy of "EmsisoftEmergencyKit.exe" which provides an EEK where A2CMD will scan in any command window. Before updating, I make a copy of the file "clean32.dll" (ver 1.0.0.173). I then update, after which A2CMD will only scan in a command window opened as administrator. This is the original problem. After updating, I replace "clean32.dll" with the original pre-update copy. Now, A2CMD will once again scan in any command window. The Cleaning Engine has recently been updated to ver 1.0.0.175, so it seems that this causes the problem. Is restricting scanning to an administrator command window desired behaviour? Thank-you for your attention.
  9. Thanks for replying. I disabled AVG Anti-virus and Zemana AntiLogger but A2CMD would not quick scan. But when I open a command window "as administrator", A2CMD completes a quick scan. So maybe this is a permissions problem? But this is still different behaviour than in the recent past, when I could scan from any non-administrator command window. And why does my VER. 1 scan without running as administrator but VER 2. does not? (see post #1)
  10. Product: Command Line Scanner version 8.1.0.31, provided with EEK version 4.0.0.17 Operating System: Windows 7 Home Premium, 64 bit, SP1 Other Security: AVG Anti-Virus Free Edition 2014, Windows Firewall, Zemana AntiLogger Free ver. 1.7.2.364 The Command Line Scanner (a2cmd.exe) does not scan. For example: a2cmd.exe /quick gives no results and Result Code (%errorlevel%) -1073741819 is returned. (see attached Screen-shot) I believe a recent update breaks the CLS. Scanning from the EEK graphic control panel works normally. I have 2 versions of the EEK "installer" (EmsisoftEmergencyKit.exe), both obtained from http://www.emsisoft.com/en/software/eek They are different sizes but I can't compare the content. 1. EmsisoftEmergencyKit.exe (VER. 1, older) - size: 220,049 KB, obtained approx. 1 month ago -before updating, CLS works normally -1st update (non-beta) includes Cleaning Engine (1.0.0.175) and requires re-start -after updating, CLS does not scan 2. EmsisoftEmergencyKit.exe (VER. 2, newer) - size: 220,219 KB, obtained today -before updating, CLS does not scan -1st update (non-beta) does not include new modules and does not require re-start -after updating, CLS does not scan For many months I have used the CLS in various scripts. I automatically updated by using "a2cmd.exe /ub" in Windows Task Scheduler. Sometimes I would open EEK contol panel and verify that the updates had been applied. They were. Then, about a month ago, the CLS stopped scanning. I deleted the old EEK and replaced it by running a new copy of EmsisoftEmergencyKit.exe (VER. 1, see above). The new CLS worked properly until after the 1st update (which included beta updates), when the CLS failed again. I then deleted EEK, reran EmsisoftEmergencyKit.exe (VER. 1), and updated without beta updates (changed command line in Task Scheduler to "a2cmd.exe /u") The CLS worked properly for some days, but then eventually failed again. I then downloaded a second copy of EEK (EmsisoftEmergencyKit.exe (VER. 2), see above) The CLS provided in this EEK does not scan, even before updating. Maybe a beta update has recently been incorporated into EEK and that is causing the problem? I noticed that the Cleaning Engine (1.0.0.175) was recently updated. Thanks for your attention.
  11. I wish you would make up your mind. First you say "There are a lot of paths that do not require quotes. Knowing which do and which do not is a matter of knowing the Windows command-prompt." Now you say "that quotes should be used for all paths." (Which was the suggestion I gave in my original post) Also, won't you acknowledge that you were incorrect when you replied "I would believe that this is the way the command-prompt works, and is not due to a2cmd itself."? The documentation is wrong/incomplete when it states "Multiple paths have to be delimited by commas". Spaces are also acceptable. See the attachment.
  12. Sorry, but that is incorrect. Do a little test. 1. Create 2 files; C:\file.txt and C:\fi,le.txt 2. Open a command window 3. Issue these 4 commands, without quotations around the paths. notepad C:\file.txt notepad C:\fi,le.txt a2cmd C:\file.txt a2cmd C:\fi,le.txt I think you will find that notepad will open a file with a comma in its path. However, a2cmd will not scan the same file. Therefore, it is not because of how the command prompt works. Agreed. But the documentation attempts to say which paths do need quotes. The documentation is incomplete because it fails to mention that a path containing a comma needs to be in quotes.
  13. I believe the online documentation for the /f switch is inaccurate and incomplete. My testing shows this: Paths that contain a comma (,) must also be put in quotation marks. As well as a comma, one or more spaces can be used as the delimiter between multiple paths. If the paths are in quotation marks, no delimiter is required. It may be sensible to advise users to always use quotation marks.
  14. Hi Christian, Thanks for re-considering your first response. I hope to see the fixed version soon. Here are a few things I have observed about the /f parameter: If the pathnames have no spaces or commas, and are not enclosed by quotes, a comma separator must be used. If the paths are enclosed in quotes, it seems that the comma separator is unnecessary. A space, multiple spaces, or no separator at all works just as well. See the command line in post #3 above. a2cmd /f="file1.ext" "file2.ext""file3.ext" is also accepted. To avoid trouble, I always enclose all paths with quotes. This seems like a logical and user-friendly way to avoid problems with separation characters that are also allowable characters in pathnames. Earlier versions of the CLS had such problems which have finally been eliminated. The new online documentation for /f mentions that pathnames with spaces must be enclosed by quotes but neglects to give the same instruction for paths with commas. It also erroneously states: "Only one path can be specified" Jim
  15. Dear Christian, Thank-you for keeping me informed. I read the new documentation but I am still puzzled by the /f parameter. Here is the pertinent documentation: Please review this thread, where I have posted evidence that seems to prove that multiple paths can be specified and scanned using the /f parameter. What is the explanation for the results shown in the quoted logfile? (reproduced below, my comments in red) I find it hard to believe that only one path can be specified with the /f parameter. Previous versions (5.0.0.19) allowed multiple paths. Allowing only one path reduces the power and versatility of the Command Line Scanner. Thanks for your help, Jim