IIS 7 550 The process cannot access the file because it is being used by another process.

Avatar
minditsolutions
  • updated
  • Fixed
We have recently updated our web server to IIS 7.

When analyzing log files we get the following error:
550 The process cannot access the file because it is being used by another process.

The error occurs when WebLog Expert is trying to download todays logfile, wich is in use by IIS7.

We have tried configuring IIS7 so that it is possible to download the log file without any luck. Others are also having this problem, but Microsoft seems not to take the problem seriously. For more information on the ISS7 FTP 550 issue, please use the following link: http://forums.iis.net/t/1159198.aspx

Anyone have a solution to this problem?
Replies 17
Avatar
0
Michael
Quote from S.
Hi,
I am currently using 7.8 Standard Trial and I wanted to exclude *.current, as I am receiving 550 errors, too (accessable by Filezilla). whateverfile.current seems to be a symlink to access.log.week.dayofweek. Anyhow, I tried to do a "/logs/access.log.*; #/logs/*.current" to parse everything except /logs/*.current. It works when I write "#/logs/*.current", but it doesn't work, when I write the above quoted command. (Unfortunately %wy% doesn't work for me, too, as my hoster seems to have a off-by-one bug with naming the logs.) :-)
It seems that the specified exclude mask doesn't match file name of the file that causes the problem. Could you please post the screenshot of the 550 error dialog? You can also send it to us privately to support@weblogexpert.com

BTW if your hoster have a shift in date when naming logs, you can try to write a wildcard like %wy-1% or similar, depending on how exactly log files are named. However, first of all it is necessary to check what is the name of the file shown in the error dialog.
Avatar
0
S.
Hi,
I am currently using 7.8 Standard Trial and I wanted to exclude *.current, as I am receiving 550 errors, too (accessable by Filezilla). whateverfile.current seems to be a symlink to access.log.week.dayofweek. Anyhow, I tried to do a "/logs/access.log.*; #/logs/*.current" to parse everything except /logs/*.current. It works when I write "#/logs/*.current", but it doesn't work, when I write the above quoted command. (Unfortunately %wy% doesn't work for me, too, as my hoster seems to have a off-by-one bug with naming the logs.) :-)
Avatar
0
Michael
We have added support for excluding files in version 7.7 beta 2. It is now possible to exclude a file name or wildcard with the # character before it along with the usual path to exclude the file(s). Here are two examples of FTP paths with exclusions:

/logs/*.*; #/logs/*.bak - analyze all files from the /logs folder except for files with the .bak extension.

/logs/*.log; #/logs/u_ex%yy%%mm%%dd%.log - analyze all .log files from the /logs folder except for today's one (date macros are used in this path).
Avatar
0
rschletty
Excellent! That would be an effective workaround. I had intuitively looked for that filtering option in WLE.

Much better than trying to schedule a server-side copy of a log in use. I don't believe I had that scripting option with WebSitePanel.
Avatar
0
Michael
Thank you for the suggestion, we'll consider adding support for exclusion of some log files from analysis.
Avatar
0
rschletty
Well, I read those two forum threads and it is amazing that Microsoft would hobble wen log downloads like this, "by design." Incredible.

Thanks for shedding as much light as you are able on the issue. I wish WLE had a log selection option that could exclude a log with the current date, perhaps by comparing the log filename to the server's system time. This filter should be included in the wildcards section of WLE.
Avatar
0
Michael
It seems that the issue depends on what FTP server is used. The best known case is the standard IIS 7 FTP server. It returns the "550 The process cannot access the file because it is being used by another process." error by default when the accessed file is used by another program. There is a setting that allows to change this behaviour but it seems that it doesn't work in some cases, you can find more information on it at http://forums.iis.net/t/1158270.aspx#B43 and http://forums.iis.net/t/1159198.aspx

As the error descriptions includes clear indication that the file is in use, WebLog Expert ignores such errors. As a result, there shouldn't be any problems when the IIS 7 FTP server is used, but there may be problems with other FTP servers while they can be probably fixed in some cases by changing server settings.
Avatar
0
rschletty
Michael, thanks for staying on top of this. I am glad you made it clear that 550 error can mean more than one thing. Anyway, I have done my laborious "workaround" by abandoning Arvixe ASP.NET web hosting and moving back to my own WinServ 2003 box on a dedicated IP.

I had started out on Arvixe's Linux shared platform but then jumped over to ASP.NET about a month ago. Not sure if I would have had this issue with Linux. I hadn't taken the time to test stats on their Linux shared server.

Am I going to have this issue no matter where I park my web sites – if they are hosted in a Windows Server 2008 environment on a shared server or a VPS? Or do you think this is just a fluke? Or is this a WebSitePanel configuration issue? http://www.websitepanel.net/

I will wrap it up by saying that I really like WebLog Professional Enterprise. You have made robust web analysis available on desktop and mobile devices (most notably iOS devices, which Google Analytics only recently started to support). Bravo.
Avatar
0
Michael
Yes, unfortunately 550 error code just means that the file cannot accessed for some reason but there may be different reasons (file locked, permission/access denied, file does not exist, etc.). Additional information on the error is provided in the description sent by server. So WebLog Expert needs to analyze this description to determine if the file is locked so it is safe to ignore it, or there is another error that shouldn't be ignored.

As for now, the program recognizes only the "550 The process cannot access the file because it is being used by another process." error as "file in use" error and ignores it. Other 550 errors including the "550 can't access file." one aren't ignored.

It's not a problem for us to add recognition of other descriptions, but the one that appeared in your case may also appear when permission is denied or file cannot be accessed for another reason, so it seems that it shouldn't be ignored.

We'll try to find some kind of solution for the issue but it seems that the best way to manage it is to use some server-side solution (like copying files) while unfortunately it's not available in some cases.
Avatar
0
rschletty
Michael: I don't think I can script anything on that shared web hosting environment at Arvixe.com. I had already tried cloning the logs folder but did not know how to automate the cloning on a schedule via the Arvixe web admin control panel. If you are talking about doing the cloning of the logs via my remote FTP program, I suppose I could try that but I assumed I would get an error if that log file happened to be "in use" at the time.

Not sure why this thread is marked as solved. You say the issue is fixed but that is not what I am experiencing . You must have seen my two screen shots that clearly report a 550 error. Are you saying that 550 can mean more than just "file in use?"

WLE version 7.6 sometimes is not ignoring an "in use" current day's log file for several of my sites. As I mentioned, one minute it can't be copied, an hour or two later, it can be copied (via both WLE and any of several robust FTP clients I have). No rhyme or reason.

Because I was spending way too much time in this and getting no satisfaction from Arvixe, I canceled my hosting with Arvixe last night and moved my nine web sites back to my Windows Server 2003 development box. There, WLE has worked very well over the past couple years. I will be very cautious in the future about grabbing logs via FTP from a shared ASP.NET hosting environment.

Perhaps my comments should be moved to a new thread and marked "not solved."