1 of 1 people found this helpful
It's probably just an oversight that the description for error code 102 is missing from the V6.0 user guide. The switch itself is still listed and supported.
I would expect the scan of a zero-byte file to be successful, not an error so it should return exit code 0, not 6.
if there were actually an error with the file - corrupted perhaps, I would then expect error code 6.
Thank you Rackroyd
If it just error code 102 is missing from the V6.0 user guide, I wonder if this is a known issue(or any patches to fix) with McAfee command line scanner V6.0 since if I scan an clean empty file with --exit-on-error option, I got exit code 102 without any message. If I scan the same empty file without --exit-on-error option, I got exit code 0.
Scan the same clean empty file using V5.30 engine is working properly return exit code 0.
This create problem for us since when we get exit code 102, it's unsure whether due to empty file (especially in zipped file) or any other problem.
1 of 1 people found this helpful
It's certainly not a know issue, or I would know about it
V6.0 has a few differences since it had to be reworked to acommodate the V2 dats and we've had a few odd bugs with some of the switches.
This hasn't been reported before though.
I must admit to being a little confused by your tests though, the difference between V6.0 and V5.3 isn't clear from your notes.
I tested V6.0 on an old-ish ubuntu version with the --exit-on-error switch and it looks to me that perhaps regardless of when it is used the exit code is always 102. Is that what you see ?
'echo $?' returns 102 for both zero and non-zero and an eicar detection files on ubuntu. It's not an exhaustive test for sure.
Retesting the same on suse 10.x it works correctly as expected returning 0 and 13 in the right places. Both were running bash shells.
If you have a detailed test case that can be used feel free to open a support case to get it investigated but my initial thoughts are this is dependent on the either the distribution or version of the shell used.
You could try a different shell maybe and see if the results are the same.
sorry about confusion. My env. is Red Hat Enterprise Linux Server release 5.4 ,My test cases as following.
I guess I may need to open a support case for further investigation.
Since I'm facing such issue with --exit-on-error, I wonder is there any problem or side effect NOT use this option. I'm working on some legacy code which invoke the uvscan and this option was working fine with V5.30 engine. not sure what could be problem if I remove this option. or, if there is any other workaround, please let me know.
My case is a bit better than your old-ish ubuntu testing. to scan a virus infect file return me code 13. non zero byte file seems works ok.
-- Test with V6.0 engine
1) under C shell:
2) cretae a clean empty file(0 byte) by:
3) run command
./uvscan --exit-on-error -secure aaa.aa
4) check exit code
5) run command
./uvscan -secure aaa.aa
6) check exit code
-- Test with V5.30 engine, repeat above steps. on step 4) and 6) both return exit code 0
-- Test by switch to bash shell and repeat above steps. got the same result
-- Test by add file aaa.aa to a zipped file and scan the zipped file, repeat above steps(replace the aaa.aa with zipped file name), got the same result.
on 12/05/10 10:55:25 CDT
Not using --exit-on-error did seem to be predictable for me with V6.0
A zero-byte file returned 0 and an eicar detection returned 13 which are both what I would expect.
I'm not entirely sure how useful this switch to be honest.
I suspect it was added a long time ago at the behest of a customer or group of customers. It's not something I would expect most customers to use so if you can work without it i'd suggest it's worth the effort.
Please feel free to log a support call to have it looked at further though if you would like us to dig into it deeper.