Re: SFTP Resume Fails
Here's some more details.
In this case I downloaded a partial file, hit abort a bunch of times, hit disconnect, and closed FlashFXP (saying yes I wanted to quit with stuff in the queue).
I then re-start FlashFXP, and it says "hey, there's a queue file!" which I re-load, and hit CTRL+R on the file that failed so it re-downloads.
This time, I ran it with Sysinternals Process Monitor, for some additional information.
I typically:
1. I hit "play" to start the download again.
2. A bunch of stuff scrolls by, and then I get the "do you want to resume?" prompt. I hit resume.
3. More stuff goes by, and I see the "do you want to resume?" prompt again. I once again hit resume.
Prior to 2, I see three CreateFile (parent folder)/QueryDirectory (with filter of the filename)/CloseFile (parent folder) events on the folder it's in (I guess detecting if it's there or not).
Then I get the prompt in 2.
After I hit "Resume", I see another two CreateFile (parent folder)/QueryDirectory (with filter of filename), CloseFile sequences, and then I see a "CreateFile" event for the filename of the file I want to resume (which is marked as SUCCESS in Process Monitor). I see a "QueryStandardInformation" event on the same file, also a SUCCESS, but then I strangely see another CreateFile request for the same file, which then fails with "SHARING VIOLATION".
Immediately after that (before the second "Resume" prompt) I see another Create/Query/Close set as I saw above, and then after a bunch of other file actions (on various desktop.ini files) another set of 3 Create/Query/Close actions (it looks like a repeat of the steps prior to 2.), and then another "Resume" prompt.
Once I hit resume again, I see some more Create/Query/Close events, and then (only one) CreateFile event for the specific file again (which again fails with SHARING VIOLATION).
I'm guessing the Create/Query/Close are directory scans looking at the file list, which make sense, but it appears once I hit resume the first time the file is opened, and then opened again (which fails, rightly so), but the first open is never closed, so the second time around, even though FlashFXP seems to behave properly and not try to open it twice, the file has never been closed from the first time.
I'm not fluent in windows processes, but asking Process Monitor for the stack at the first CreateFile request (which works) looks almost exactly like the second, except for frame 13:
-"13","FlashFXP.exe","FlashFXP.exe + 0x1f376a","0x5f376a","C:\Program Files\FlashFXP\FlashFXP.exe"
+"13","FlashFXP.exe","FlashFXP.exe + 0x1f3622","0x5f3622","C:\Program Files\FlashFXP\FlashFXP.exe"
the + is the one which "works" (the first one, that seems to get "lost")
|