0

Is it possible that deleting files from a Windows 2003 R2 command prompt, could be deleting the wrong files?

We have a voice recording server thats sole purpose is to listen in on phone lines and record what it hears to a wave file.

Per client requirements, we are required to keep these calls for 90 days, so every monday, i have a batch job i run (just a simple .bat file) that i increment the files i want to delete (del a_yyyymmdd*) and run it

after years of operating like this, we think windows is deleting the wrong files. for example, this week, i would have deleted feb 09- feb-13 (3 months ago)

but we're finding that it deleted last weeks phone calls

i'm positive my batch job is coded properly, i've been doing this every monday for the last 4 years

we've decided to not run the batch job next monday and see what happens, but has anyone seen this?

a little more specific - there are 10000's of these files in the folder per the call recording software vendor, we do nothing to this server; no service packs, no updates, no antivirus, nothing. its truly, internal, specific purpose.

i think its some sort of file system corruption

any ideas?

-------- the batch file with client names converted to #'s --------------

cd cappman

copy rec_06\a_20110130*####* ####
copy rec_06\a_20110131*####* ####
copy rec_06\a_20110201*####* ####
copy rec_06\a_20110202*####* ####
copy rec_06\a_20110203*####* ####
copy rec_06\a_20110204*####* ####
copy rec_06\a_20110205*####* ####

copy rec_06\a_20110130*####* ####
copy rec_06\a_20110131*####* ####
copy rec_06\a_20110201*####* ####
copy rec_06\a_20110202*####* ####
copy rec_06\a_20110203*####* ####
copy rec_06\a_20110204*####* ####
copy rec_06\a_20110205*####* ####

cd rec_06
del /q a_20110130*
del /q a_20110131*
del /q a_20110201*
del /q a_20110202*
del /q a_20110203*
del /q a_20110204*
del /q a_20110205*

cd..

copy rec_07\a_20110130*####* ####
copy rec_07\a_20110131*####* ####
copy rec_07\a_20110201*####* ####
copy rec_07\a_20110202*####* ####
copy rec_07\a_20110203*####* ####
copy rec_07\a_20110204*####* ####
copy rec_07\a_20110205*####* ####

copy rec_07\a_20110130*####* ####
copy rec_07\a_20110131*####* ####
copy rec_07\a_20110201*####* ####
copy rec_07\a_20110202*####* ####
copy rec_07\a_20110203*####* ####
copy rec_07\a_20110204*####* ####
copy rec_07\a_20110205*####* ####

cd rec_07
del /q a_20110130*
del /q a_20110131*
del /q a_20110201*
del /q a_20110202*
del /q a_20110203*
del /q a_20110204*
del /q a_20110205*

cd ..


cd rec_06
del /q a_20110301*####*
del /q a_20110302*####*
del /q a_20110303*####*
del /q a_20110304*####*
del /q a_20110305*####*
del /q a_20110306*####*
del /q a_20110307*####*

cd..

cd rec_07
del /q a_20110301*####*
del /q a_20110302*####*
del /q a_20110303*####*
del /q a_20110304*####*
del /q a_20110305*####*
del /q a_20110306*####*
del /q a_20110307*####*

just checked event viewer this morning - nothing out of the norm; my recent reboots, group policy syncing, etc...

on top of all of this, the folders listed above aren't the primary recording folder - every 3 weeks or so, i rename the main rec folder to rec_0# to try to cut down on how many files are in the main folder. the recording program is old; it doesn't have a means of retention date so i've had to deal with it on my own; so files being deleted from last week, is absurd because we're not even deleting files from the main rec folder (where those files are) - we're deleting files from these other folders (reason for doing the delete on 06 and 07

like i said, where you see the #### is a client name; the differences in deletes and copies is the difference in keeping some clients calls for a longer time, or a shorter time.

-Mario

8
  • 4
    Pasting or pastebinning the batch script in question along with a sample list of filenames may be helpful.
    – Hyppy
    May 17, 2011 at 19:44
  • has the startup directory for the script changed and are the paths absolute not relative?
    – tony roth
    May 17, 2011 at 22:07
  • no startup folder, i manually run the batch file every monday morning
    – lsiunsuex
    May 18, 2011 at 10:44
  • the batch file is located in the root of d:\ btw - cappman is a folder in the root of d:\ so d:\cappman; d:\cappman\rec_06; etc...
    – lsiunsuex
    May 18, 2011 at 10:53
  • so looking at the script if your not in the root dir of the d: drive things won't work correctly, right?
    – tony roth
    May 20, 2011 at 13:01

3 Answers 3

6

Either the batch script is coded wrong, or the files were named wrong. Windows won't just make up a file to delete if it's having a bad day.

4
  • I can't post the batch file; doing so would expose our clients names; the format for the file name is what i posted above; a_yearmonthdate_b_clientname_c_channel_d_etc...wav - i own this entire process since its implementation - i designed it - the batch file is correct; had my boss double check it. has to be something else; file fragmentation? corrupt raid 5 set? corrupt ntfs file system?
    – lsiunsuex
    May 17, 2011 at 20:50
  • 3
    @mario No it can't be. Either the files where named wrong, or the batch file is wrong. Those are the only two options. Also you should be checking the CreationDate or LastModifiedDate file properties as they would be more reliable, or give you a sanity check.
    – Zypher
    May 17, 2011 at 21:27
  • 4
    @Mario no offense but if you're suggesting that file fragmentation might be at fault, I have a hard time taking you at your word that the batch script is coded properly.
    – MDMarra
    May 17, 2011 at 21:27
  • batch file posted. suggesting file fragmentation is me reaching for something; i've never seen this, and until this, i'd have thought i was out of my mind as well.
    – lsiunsuex
    May 18, 2011 at 10:45
1

The best way to troubleshoot this would be to set up a dummy environment, populate it with example data (or copy over the production stuff), and test the script that way.

If you really had NTFS errors or a corrupt RAID controller, you'd be seeing errors verily fly out of the event viewer. Since you haven't mentioned those, I'm assuming they're not happening. The most likely culprit is your batch, and the easiest thing to do is test it on a non-live system.

2
  • checked event viewer this morning; nothing out of the norm as i mentioned in my edit above; a dummy environment is extremely difficult; these are hard wire taps on the phone lines; this box has 5 dialogic cards in it, each capable of whatever # of lines; to reproduce the box is to buy more cards, which we're not going to invest in. there are literally 100,000's of files (we're a 400 seat call center) - i cant just pickup the recording folder and move it to another box :( i wish i could; i hate 1 off's, but i dont have a means to
    – lsiunsuex
    May 18, 2011 at 10:48
  • You don't need to copy over the whole recording folder. Just enough to be able to test the script. It's nothing special really. You just need a box with some space, a folder structure to mimic production, and a few files to test with. May 18, 2011 at 13:46
1

here's a duh type thought, run the script steps manually.

You must log in to answer this question.

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