I agree there shouldn't have any dereference during cleanup.
But, this is actually fixing the leak in renaming process (only
happens). That one is pretty hard to track. Jérôme and I had bad moments
on that one.
This leak doesn't happen in normal working of the FSD, but only in
renaming operations. Fixing it would likely fix most (all?) of the
renaming issues.
On 05/11/2014 20:53, Thomas Faber wrote:
Oh... Jérôme, I only just saw that you added this in
r65140...
And my change does break the msi tests again. :\
Any idea what's going wrong here?
I'm relatively certain my change is correct because
vfatFCBInitializeCacheFromVolume takes one reference, and VfatCloseFile
invoked via ObDereferenceObject will remove that reference again.
So apparently we're leaking a directory reference somewhere else? :(
Not sure if your previous investigation into this issue can provide any
pointers. Otherwise I'll have to start digging for the leak all over
again...
Thanks.
-Thomas
On 2014-11-05 19:52, tfaber(a)svn.reactos.org wrote:
> --- trunk/reactos/drivers/filesystems/fastfat/cleanup.c [iso-8859-1] (original)
> +++ trunk/reactos/drivers/filesystems/fastfat/cleanup.c [iso-8859-1] Wed Nov 5
18:52:11 2014
> @@ -92,7 +92,6 @@
> pFcb->FileObject = NULL;
> CcUninitializeCacheMap(tmpFileObject, NULL, NULL);
> ObDereferenceObject(tmpFileObject);
> - vfatReleaseFCB(IrpContext->DeviceExt, pFcb);
> }
>
> CcPurgeCacheSection(FileObject->SectionObjectPointer, NULL, 0,
FALSE);
>
>
--
Pierre Schweitzer <pierre at reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.