scans not completing, anti virus disabled

[bobkoure]

Since I jumped from the 1/31 build to the 2/5 build my scans have not been completing.
I looked through scanner.log, and it looked like a problem with anti-virus "autoprotect"
execute failed: Can't create/write to file 'C:\WINNT\TEMP\#sql_e18_0.MYI' (Errcode: 13)
So I made sure that C:\WINNT\TEMP and the MYI filetype were on my A/V's "ignore" list.
Still no success, so I disabled the A/V "autoprotect" (the part that might cause this kind of problem).
Still no success.
I then removed almost all the links to music directories (I've music in a number of different directories - originally for audiotron compatibility, now just historical).
I made a point of retaining the links to the directories containing about 250 compilation albums (I'd thought this might be the problem as the scan would invariably fail somewhere in "merge various artists.
I thought I'd isolated the problem, so I would get a failure quickly, rather than having to wait over an hour to see if the scan was going to fail again.
Only the scan worked (!)
If I go back to all directories, the scan fails again.

I'd love some suggestions as to what to do now, as this has absorbed more of my time than I really have available (looming deadlines for some other projects). Help?

Thanks!

PS: I'm running on a Win2KServer PC, SC is running as a service. I've had this problem both with it running as the local system account and running as me (member of admin group)

[bobkoure]

I've tried this again with the antivirus stuff completely removed (rather than just disabled)
Same problem.
Sigh...

[bobkoure]

I uninstalled SC7, re-installed SlimServer_6.5_v2008-01-30, rescanned all my music - and it seems to have worked(!?)
I'd be more positive of this if someone could point me at the location of the SS log files? As it is, using the SS website to "see all recent errors" beings me to a one-liner:
Warning: Migrating from 6.3.x used with MySQL!
... and that's it.

[bobkoure]

Updated to 02-08 SC - scan failed (again).

Am I the only one running SC on a W2KServer PC?

BTW, I'm wondering if this is related to the MySQL "temp file permissions" issue...(?)

[bobkoure]

OK, mea culpa for asking for w2k help here.
Have submitted as a bug - just wanted to be sure it was actually a bug and not something stupid I was doing...

[mherger]

> BTW, I'm wondering if this is related to the MySQL "temp file
> permissions" issue...(?)

I would have asked about it, if I hadn't been away for the weekend :-). I'm following up on the bug. Thanks.

--

Michael

[bobkoure]

So... is there anything else I can check to make sure you aren't going to unnecessary trouble?
and Thanks!

[mherger]

> So... is there anything else I can check to make sure you aren't going
> to unnecessary trouble?

From the bug report:

Very likely not a bug, but unlucky configuration: What's that "anon" user? If
this is a user of yours, does it have write permission to the temp folder? By
default users can't write inside the Windows folder, can they? I don't remember
the details in w2k, but either giving that user write permission to Windows and
Windows\Temp, or moving the temp folder to c:\temp should imho fix this issue.

Would SC run if you made it run _without_ setting a user, thus running it under
the default SYSTEM user?


--

Michael

[bobkoure]

Oh, sorry - by "anon" I meant the local system user.
Glad you asked.

I have this same problem when the service runs as me - a member of the administrators group.

I'm not sure there's any way I can run as that local system user in order to test create/modify access. I'd thought that I could schedule a job and it would default to that, but I guess I'm either misremembering or remembering from the wrong version of windows. Sigh.

Is SC (or MySql) using %temp% to figure out where to create a temporary file? I could just change that...

[bobkoure]

Update:
I did a fresh install of Win2K server, then SP4 (needed so I could access large drives), downloaded and installed the most current SC (c2008-02-14), and did a full scan.

It worked fine.

I suspect that the issue was some part of Symantec Corp anti-virus deciding that it was going to "protect" me against whatever nasty-bit-pattern it was finding in that temp file, even though I'd set it to ignore the temp directory and files with that extension.
I spent quite some time researching all the different ways that this particular A/V might not uninstall, and then making sure those "bits" were either not present or not deleted - and scans were still failing, so maybe it wasn't the A/V.
On the other hand, the "sudden" onset of this problem where the only thing I'd done was "up" a SC version could easily be explained by the A/V getting a new definition file.

So... I dunno.

But I do know that it's not a SC fault.

Best,
Bob

[snarlydwarf]

I suspect that the issue was some part of Symantec Corp anti-virus deciding that it was going to "protect" me against whatever nasty-bit-pattern it was finding in that temp file, even though I'd set it to ignore the temp directory and files with that extension.

Glad you got it working. From what some have said here, certain AV packages are a pain in the butt to really remove. "Well maybe it isn't the user trying to remove me, but a trojan! I'll show them, I'll just hide and keep running!"

The worst thing about computers and software is when the believe they are doing the 'right thing' and being 'smart'.

People are far smarter than software, and it should just do as it is told instead of pretending to.

[bobkoure]

Seems like all antivirus programs would need is to ask for a password - a bit like sudo.
... not that I'm at all sure that that was my problem...