FTP / IIS4.0

I've got an FTP client that GETs a file from my FTP Server (IIS 4.0) then
Deletes the file after getting it.  Pretty simple batch file.  Goes
something like this:

Open the connection....
Then close the connection (you get the idea)

I've got it running every 5 minutes or so.  Works great "most" of the time.
Here is the strange thing.  Every once in a blue moon (about every 3 weeks
or so) the MDELETE fails to work, but the MGET continues to work.  Well,
this causes chaos because every five minutes; the same file is retrieved
over and over.

When this fails, I've tried to manually ftp to the server and delete the
file (with Admin rights), but I get "Access Denied" when I do a DELETE

Finally, when I stop the FTP services (through IIS) and start the services
the MDELETE *.XYZ works like a champ.

Does anyone know why my FTP server would intermittently deny a DELETE
command until stopped and started?  I've looked for a trend in the logs, but
I am unable to find any.

Thanks in advance.
Who is Participating?
andyalderConnect With a Mentor Commented:
Maybe worth putting "wait.exe 20" (or sleep.exe) inbetween the mget and the mdelete incase the mdelete starts before IIS realises mget has finished.

I haven't had this problem with IIS but I have seen it with other FTP servers.
hi spriolo,

do you call the size property when doing the batch?


is about that problem

another one, and maybe more obvious is about locked files that can't be deleted


Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

sprioloAuthor Commented:

In the little batch script I do not "PUT" and files on the server.  Only MGET and MDELETE.

This is the same research I found in the KB.  I'm looking into the transfer being interupted, but this takes time.

Has anyone had a similar problem with their ftp server?

I posted that article because it's the same principle.  Your mget caches the file, and may be locking it just as described by the article.

Good luck...
klover, have just read the article you posted, same as I think. Agree PUT is unimportant, there's a race condition.
sprioloAuthor Commented:
Does anyone know of a tool that will watch the directory in question for this event?  Maybe a service...

An update:  I've set the batch script to wait between the MGET and the MDELETE.

As far as the TechNet articles.  Here is a strange finding:  When the file in question does not get deleted; the future files placed in this directory do not get deleted either.  All of the files are successfully transfered, but when the delete of one file fails, the future files fail to delete also...

I think this behavior rules out a file being locked because of an interupted file transfer.  I'm not sure though.

Any thoughts?
what does the eventlog return?
Try a good 'ole netstat -n on the server and/or the workstation after the FTP session to see if any ports are hung open.  I've been having this problem at a client where multiple computers check the same mailbox.  About once a week, I have to have one of the users reboot because even though she has quit her mail program long ago, a netstat shows her connected to the mailserver, blocking access to that account by other users.

Maybe it's the workstation, have you tried it from another client?
sprioloAuthor Commented:
Bruinte: this is the thing.  The evenlogs are clean from any errors.  The ftp logs show issues though.  the ftp logs show tons of "sent" line items (to be expected); but other than that I'm getting an error free failure.

Using netstat -n will help, but the in the case of this ftp session wich happens every 5 min. 24 hours per day 7 days a week. (thats 2016 sessions per week).  This tends to become tedious.

I'm looking for a tool that will maybe look at a folder and listen for "non-activity / activity".  I'm really not sure what could be used here.
Try shutting down your MS FTP, and put up one of the shareware ones for a while.  Maybe this will haelp you debug it.
I swear I am having de ja vu and have seen almost the exact question posted here previously, but I am not sure how to search the archives (I don't get on here much)

As I recall, the answer had to do with setting a default timeout on the FTP server to stay open longer for the MDELETE to have a chance to finish

Or I could just be blowing smoke
You didn't say what the size of the files that you are transferring are.  If the files are large, then MGET will take longer to complete.  Try increasing the interval of the wait between the MGET and MDELETE commands.
Also, you may want to add a wait between MDELETE and the CLOSE command to allow the file to finish being deleted before you attempt to close the connection.
Hope it helps!
sprioloAuthor Commented:
lbmacbride: The files are about 25K.  All text.  they arrive via a mapped drive on an EDI computer and leave via FTP/IIS4.0 to a Unix server.

I've placed a pause between the commands, I'm not sure if this has solved anything but I am now unable to duplicate the failure.

who should get these very ambiguous points?
This seemed to be a team effort...   but you are the final arbiter for the answer.  I think that if you cant duplicate the failure, then it's solved.


klover's article was the first to suggest putting in a wait between the mget and mdelete
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.