[FYI] Eliminating the delay when deleting in-use files/dirs

Lefteous · Post by *Lefteous » 2006-05-20, 07:27 UTC

2icfu

This is a severe problem imho, unfortunately ghisler hasn't commented my concern in that thread:
If you try to delete a locked file to the recycle bin (from a supported drive) and successfully manage to unlock the file when DeleteFile() is executed (between 5 and 10 seconds waiting time), your file will not wait for you in the recycle bin but will be nuked by DeleteFile()...

Exactly

BTW: The question remains: Why is the delayed reduced to 0? DeleteFile shouldn't be affected by the change.

SQUIRE · Post by *SQUIRE » 2006-05-20, 09:16 UTC

"That was too fast, you haven't tried your best to nuke that file.
.
.
.
Bill: 0 is too few, 10 is too much, let's take the middle.
Steve: All right, you are the boss.

Think about all the hype if 23 tries would be made...

Heh, heh. I take it that's a thumb's down for the Bill 'n Steve Show from icfu. Imagine if they'd used the answer to Life, the Universe, and Everything.....

Anyway, regard me as your testing dummy.

Yes, please! Particularly interesting would be unattended MOVs rather than plain DELs to see if identical files/folders are left hanging around.

ghisler has already given an answer in this REQ thread....your file will not wait for you in the recycle bin but will be nuked by DeleteFile()...

Ouch, that's bad news - hope that's fixed come v7.0

SQUIRE · Post by *SQUIRE » 2006-05-20, 10:35 UTC

If you try to delete a locked file to the recycle bin (from a supported drive) and successfully manage to unlock the file when DeleteFile() is executed (between 5 and 10 seconds waiting time), your file will not wait for you in the recycle bin but will be nuked by DeleteFile()...

Well, I just tried this:

[1] Start playing an mp3 in Apollo
[2] Press DEL on the file.
[3] After 10 secs TC says 'cannot delete', as expected.

then the next time

[4] Press DEL on the file
[5] While TC's wait dialog is up, and within about 2 secs, ALT-F4 to kill Apollo and release the lock.
[6] TC deletes the file
[7] Look in RECYCLE, and the file is there and hasn't been nuked as promised.

I tried this 3 times with varying delays (while TC was waiting) before unlocking the file and each time the file was correctly deleted into the recycle bin.

If I read the quote right I should have lost the file. So what's going on? The problem doesn't seem to occur here. Is there some particular set of circumstances or sequence of operations that's needed to cause the bad result?

(WINXP SP2, TC 6.54)

XPEHOPE3KA · Post by *XPEHOPE3KA » 2006-05-20, 12:09 UTC

varying delays

Was any of your delays above 5 seconds?

SQUIRE · Post by *SQUIRE » 2006-05-20, 12:23 UTC

Was any of your delays above 5 seconds?

Yup, 7-8 secs. Try it yourself and see if you can get your file nuked. I couldn't manage it.

icfu · Post by *icfu » 2006-05-20, 12:26 UTC

If I read the quote right I should have lost the file.

Yeah, that's what I had thought at least and as ghisler hasn't commented it in that thread...

So what's going on? The problem doesn't seem to occur here.

Honestly I have no clue, sorry. Indeed the file is still there, although DeleteFile() is called according to ghisler after the first try.
I have tested it again now with patched and unpatched shell32.dll.

So, there is no bug but I don't know why. Probably it's related to the question:

Why is the delayed reduced to 0? DeleteFile shouldn't be affected by the change.

I can only assume that ghisler does NOT call DeleteFile then...

Icfu

Alextp · Post by *Alextp » 2006-05-20, 12:45 UTC

majkinetor
Anyway, even if you will not make content plugin, you'll make DLL containing functions:

function GetLocker(fn: PChar; var LockerBuf: PChar; LockerBufLen: DWORD): BOOL;
// it must cache data!
function Unlock(fn: PChar; MaxTimeout: DWORD): BOOL;

Ghisler may use both functions, but content plugin - only first one.

About driver: will it support both NT and 9x, or we'll need 2 drivers?

PS.
LockedTest source:
http://atorg.net.ru/files/wdx_UnicodeLockedTest_src.rar

SQUIRE · Post by *SQUIRE » 2006-05-20, 12:47 UTC

Hmm, I suspect he probably doesn't call DeleteFile() then, because it's illogical to follow a failed DEL-to-bin request with an unconditional DEL.

That would really get the user hot and bothered!

icfu · Post by *icfu » 2006-05-20, 12:54 UTC

So, you suspect the same, that's nice to hear. But, if this is the case, why does ghisler tell it? Mysteries...

Besides that: Does anyone know a decent API monitor? I have tried APIMON from XP Support Tools, but unfortunately it doesn't show me SHFileOperation call.

API Monitor from http://www.rohitab.com/apimonitor/ on the contrary doesn't work at all with TC, at least here. Can anyone confirm that?

Icfu

Lefteous · Post by *Lefteous » 2006-05-20, 13:21 UTC

2icfu

Does anyone know a decent API monitor? I have tried APIMON from XP Support Tools, but unfortunately it doesn't show me SHFileOperation call.

http://www.matcode.com/apis32.htm

It's ok just to see if a function is actually called.

icfu · Post by *icfu » 2006-05-20, 14:15 UTC

ghisler calls SHFileOperation TWICE!
Does that make any sense? Why does he tell that story about FileDelete on the second try? I am rather confused now...

Anyway, APIS32 is really cool, I have dumped all other API monitors.

Icfu

Lefteous · Post by *Lefteous » 2006-05-20, 14:41 UTC

2icfu

ghisler calls SHFileOperation TWICE!

Just as I suspected here:
http://www.ghisler.ch/board/viewtopic.php?p=88145#88145

Does that make any sense? Why does he tell that story about FileDelete on the second try? I am rather confused now...

So he calls SHFileOperation with the FOF_ALLOWUNDO flag first (that means try to move to the bin first) and then without FOF_ALLOWUNDO (try to delete the file directly). Of course SHFileOperation uses DeleteFile internally... That explains why this patch reduces the delay to 0 seconds. Thanks for your investigation.
If this makes any sense? No I don't think so.

icfu · Post by *icfu » 2006-05-20, 15:00 UTC

Just as I suspected here:
http://www.ghisler.ch/board/viewtopic.php?p=88145#88145

I had overlooked that, sorry.

So he calls SHFileOperation with the FOF_ALLOWUNDO flag first (that means try to move to the bin first) and then without FOF_ALLOWUNDO (try to delete the file directly).

I don't get that I think. If the second try is done WITHOUT FOF_ALLOWUNDO flag, how can the file end in the recycle bin if it is unlocked after the first 5 seconds?

Of course SHFileOperation uses DeleteFile internally.

Shouldn't it be deleted then, just like when calling DeleteFile directly?

Icfu

SQUIRE · Post by *SQUIRE » 2006-05-20, 15:19 UTC

It would be completely nutty to insist on deleting a file at all cost just because the first DEL-to-bin failed. A user expecting to find it always in the RECYCLE bin would be rightly horribly upset.

No, I think it's simply a second identical call to to DEL-to-bin if the first fails for whatever reason. Just being a little over-zealous I guess.

Personally, I would've just jumped out after the first failure and given the user the dialog to retry if he wanted to.

That would have saved 5 seconds!

Lefteous · Post by *Lefteous » 2006-05-20, 17:03 UTC

2icfu
I see. So it seems the function is called twice with identical parameters.