1

I have a few processes on server windows 2003 servers (latest service packs, etc) that exhibit the same problem: a random failure to delete a file they should be able to delete. This happens both from software I've written and from batch files (run from the task scheduler).

For example: I have a program that opens an existing file then creates a log named the same as the file except with a different extension. When my program is done processing the file, it moves it to a subdirectory called "done" and then deletes the log. Sometimes, however, my delete fails. There is no virus scanner installed on the machine that might keep the file open. My software is the only software that does anything with this file - heck, it created the file. And, yet, the file fails to delete. This software processes over 5000 files a week. Some weeks I'll never get the error, others it will happen one or two times, apparently randomly. It is not a rights access thing and I'm baffled. It is not a problem I can replicate on demand; it just happens sometimes. It happens on multiple servers and from batch files as well as from my software.

Has anyone encountered anything like this? I put an error trap in the delete and it appears to be getting an "Accessed Denied" type of error on delete.

--- ADDENDUM Just another note: yes, I tried delaying the delete after I close the file (see comment below). Further, one of the batch files that I have does this:

if exist my_lockfile.txt goto exit_this_batch
echo here is a lock file > my_lockfile.txt
call someother_program
call more_programs
call there_is_always_a_delay_of_at_least_a_minute_here
del my_lockfile.txt
:exit_this_batch

This batch file above about 1 in 10000 times will fail to delete. The delay between the creation with echo and the del is always at least a minute. Weird.

1
  • Where are the files located? On a local hard drive or a NAS device? Apr 30, 2009 at 18:47

2 Answers 2

2

I've encountered behavior like this while running the Volume Shadow Copy service and if applicable the SQL Server VSS Writer (it used to exhibit some bugs.) If that service is not crucial to your server or if you can temporarily turn it off, try turning it off and see if you can still reproduce the problem.

3
  • ah, good thought. i think the volume shadow copy is running on that machine and i know i don't use it. i'll try shutting it down. thanks. May 3, 2009 at 0:33
  • Please note that it's a shot in the dark. VSS should not cause behavior such as you have encounter. However, there's a certain distance from "should not" to "does not" we like to call "implementation details"... :) May 3, 2009 at 0:58
  • i hear you:) i'll disable it tonight and see if i can make it a week with no errors. if so, i'll mark this the accepted answer. thanks again. May 4, 2009 at 12:43
1

If you delay the file delete by just one second, does the problem go away? Are you capable of doing so? If that is the case, it's a potential locking issue, maybe even from the original process.

EDIT

Since it's not a file locking issue by the original process, are there multiple processes that peer into the directory in question?

4
  • oh ... i should have mentioned that ... no, it doesn't help. i went so far as putting a sleep 2000 after the close of the file and before the delete. Apr 30, 2009 at 18:43
  • nope. there is no virus scanner on this server. i can't think of anything else that does anything with this folder. nothing even scans it. files are moved into it via batch file and the windows "move" command. the files that are failing to delete are created by the process that is deleting them. very odd. thanks for sticking with me on this K. Brian. Apr 30, 2009 at 19:45
  • We just added a new drive to one of the dev servers in my environment and went to look at properties... Indexing Service. Turn off the ability for indexing for that folder. See if that makes a difference. Apr 30, 2009 at 20:56
  • nice, that's something i hadn't thought of. unfortunately, though indexing was turned on on the c: drive ... it was off on the d: drive. d: is where the program and data reside:( thanks though, good thought. May 1, 2009 at 2:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .