We are running FinalBuilder through CCNet using the CCNet plugin.
We were experiencing problems where occasionally the version used for the build were not the latest checked into ours source control. (Vault)
To be on the safe side, I moved the “Get Latest” from CCNet into FinalBuilder - and I also added cleanup tasks in finalbuilder that delete all folders before getting everything fresh from source control.
This seems to cause the following reproducible error:
1 - First build is successfull
2 - Second build crashes when trying to delete the SW folder - "Access Denied"
I added an error handler when the Delete Directory action failed, and in there I call handle.exe from www.sysinternals.com in order to list all handles that are open.
The folder we try to delete is c:\FinalBuilder\Vault\Applications\FarmManagement\SW - and this is currently opened by FinalBuilder. I use a folder iterator to delete the folders - is it possible that this iterator does not release the handle in time for the delete directory action? If so - why does it work the first time…
This is the output from handle.exeFarmManagement.fbp4 (292.664 KB)
Hi Espen,
I think I know why you are having this problem, and also why you are seeing this open handle after the error returns.
The problem is caused by the fact that you can’t really use the Folder Iterator for deleting folders recursively. The Folder Iterator returns each parent subdirectory before the child directories, so by the time the child directories roll around they’ve already been deleted.
The best way to delete a directory and all subdirectories is to use the Delete Directory action with the ambiguously named “Delete Tree” option set. I just changed this option so it will be labelled “Delete All Files In All Subdirectories” from now on.
The reason that you are seeing the leftover open handle (and possibly the access denied errors) is a bug in Delete Directory with Delete Tree enabled, where the handle wasn’t being closed if an exception was raised. I’m guessing that this is why the Access Denied appears the second time around.
We’ll have a fix for the open handle bug available in the next test build, but in the meantime you can probably get by with just the Delete Directory action (I’m assuming that you do not need to filter the list of directories that need deleting?)
Sorry for the inconvenience.
Regards,
Angus
Thanks for your reply.
The problem is that I _do_ need to filter the list of directories - I am performing cleanup before executing a "Get Latest" from source control.
The FinalBuilder task resides in source control, that is why I used the Folder Iterator, so that I do not attempt to delete the folder with finalbuilder in it.
I guess I will have to wait for the patch to be published...
Do you have a date for the next release?
Espen
Hi Espen,
Here is a test build with the open handle bug fixed:
https://www.finalbuilder.com/downloads/finalbuilder/420/FB420_285.exe
You may wish to try using FileSet Define and then FileSet Delete to clean out your file tree. You won’t be able to delete the action directories, but you can clean out and/all files and use filters to determine which files to delete.
Regards,
Angus
You guys are great! I am downloading now, and will let you know if the problem reappears!
Espen
I am sorry - but I am no closer to resolution. Our server has been running fine for a week, but yesterday I upgraded to Nant 0.85.RC4 and MBUnit RC2 - and now it seems to be reproducible - every 2nd build fails -
From the FinalBuilder log:
Unable to Delete Directory : c:\FinalBuilder\Vault/Applications/FarmManagement\SW
System Error. Code: 145.
The directory is not empty
I immediately call handle.exe: and the only place it mentions the SW folder is under FBCMD.exe:
FBCMD.exe pid: 3920 MERCATUS0\aspnet
14: File (RW-) C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.1830_x-ww_7AE38CCF
138: Section \RPC Control\DSECf50
200: Section \BaseNamedObjects\Cor_Private_IPCBlock_3920
208: Section \BaseNamedObjects\SharedPerfIPCBlock
2A4: Section \BaseNamedObjects\NLS_CodePage_1252_3_2_0_0
33C: Section \BaseNamedObjects\NLS_CodePage_850_3_2_0_0
6DC: Section \BaseNamedObjects\__NexusMM4__500F0000
764: Section \BaseNamedObjects\madExceptThreadNameBuf$f50
768: Section \BaseNamedObjects\madExceptSettingsBuf$f50
7A0: File (RW-) C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.1830_x-ww_7AE38CCF
7E8: File (RW-) C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_5.82.3790.1830_x-ww_1B6F474A
7F0: File (RWD) C:\FinalBuilder\Vault\Applications\FarmManagement\SW
840: File (RW-) C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.1830_x-ww_7AE38CCF
1088: File (R--) C:\Program Files\FinalBuilder 4\FB40ActionCtx.dll
10AC: File (R--) C:\Program Files\FinalBuilder 4\ActionDefs\FB40CustomActionInterfaces.tlb
1100: File (---) C:\DOCUME~1\aspnet\LOCALS~1\Temp\NexusDB_TemporaryStorage_3920_2142568608.tmp
1108: File (---) C:\FinalBuilder\Vault\Applications\FarmManagement\Test\FarmManagement.lck
1118: File (R--) C:\FinalBuilder\Vault\Applications\FarmManagement\Test\FarmManagement.fbl4
111C: File (RW-) C:\FinalBuilder\Vault\Applications\FarmManagement\Test\FarmManagement.fbl4
115C: File (RW-) C:\
A bit later in the project, I try to get the latest source from vault:
[Vault Get Project from $/Applications/FarmManagement]
Running Vault with command line : get -user "******" -password "******" -host "**********" -repository "*********" -destpath "c:\FinalBuilder\Vault/Applications/FarmManagement" -setfiletime "modification" -makereadonly -merge overwrite -performdeletions removeworkingcopy "$/Applications/FarmManagement/"
Access to the path "c:\FinalBuilder\Vault/Applications/FarmManagement\SW\3rdParty" is denied.
This seems a bit strange, since the 3rdParty folder is not mentioned by handle.exe...
Any suggestions?
Hi Espen,
I’ve just spent quite a while chasing possible avenues for this, and I have a few theories:
Are those forward slashes in your directory name typos? They seem consistent, so if they aren’t typos then that may be your problem.
If not, it looks to me like FBCMD is opening that handle because ity is using the SW directory as the process’ “Current Directory”, which is quite odd. It may be that CC.Net is setting it on process launch - I’ve just updated the CC.Net plugin to explicitly set the working directory on startup (to the parent directory of the project file.) Will let you know when the new build is available.
This is still odd because the Delete Directory action explicitly sets the current directory to the root level (to avoid this problem), so it shouldn’t be the cause.
Finally, if none of this helps, is it possible for you to add some “handle -p FBCMD.exe” Execute Program Actions into your build process? Maybe at the very beginning, and before each of the actions which fails? This may help pinpoint at what moment the handle is opened.
Regards,
Angus
After I posted here, it is no longer reproducible - the last builds have gone fine, without any changes to the FinalBuilder task.
I have modified the project to call handle.exe at the start of the build, before each call to Delete Dir and if the build fails.
I have also modified the paths to use “” instead of “/” - is used the “/” because that is required by the Vault - and then I could have the path in only one variable.
I will let you know if the problem reappears.
Here is the latest log - it failed after the second build: FBCMD.exe has version 4.1.0.228
As you can see - FBCMD does not hold a handle to the SW_DataContext folder before the Delete Action is being run
[If [c:\FinalBuilder\Vault\Applications\FarmManagement\SW_DataContext] <> [c:\FinalBuilder\Vault\Applications\FarmManagement\Test]]
[Execute Program [ c:\program files\sysinternals\handle.exe ]]Content trimmed.
SORRY SORRY SORRY SORRY.
I just went in to doublecheck the version of FBCMD.exe - it was 4.1.228. I have no idea how that could have happened, I am 99% certain I installed the fix you made. I am reinstalling the fixed build now - I will let you know if there are still issues.
Actually, this is more a question than a reply.
I happened to have similar problem in deleting directory recursively. Final Builder log gave me the following output: System Error code: 5, Access is denied. As soon as I closed final builder, I could delete the directory manually from explorer.
Our final builder version is 4.2.0.305.
Is it still a known problem with DeleteDirectory?
thanks
This is not a known problem, and FB doesn’t (or shouldn’t) hold on to directories. If you can send us a reproducible case, I’d be happy to take a look.
.t8
I have had recurring problems with deleting directories. A couple of observations:
* Sometimes attempting to delete a directory by the wrong name gives the “access denied” error.
* Sometimes, repeating the delete attempt at 3 second intervals succeeds - there’s some race condition there.
* If all else fails, just delete the contents of the directory, and leave it empty. The normal reason for wanting to delete a directory is because you’re about to recreate it anyway.
Steve