Folder is locked when expand the folder in left hand side about winfile HOT 2 OPEN

Odd! Can reproduce.

from winfile.

I think this is due to current directory handling:

00 00000089`2a442af0 00007ffa`7b73c5c4     ntdll!NtOpenFile
01 00000089`2a442af0 00007ffa`7b73c1c4     ntdll!RtlpCreateNewDirectoryReference+0x8c
02 00000089`2a442b90 00007ffa`773a8be8     ntdll!RtlSetCurrentDirectory_U+0xf4
03 00000089`2a442bf0 00007ff6`2fdece54     KERNELBASE!SetCurrentDirectoryW+0x28
04 00000089`2a442c10 00007ff6`2fd82ab4     Winfile!SetWindowDirectory+0x64 [c:\src\github\microsoft\winfile\src\wfutil.c @ 1082] 
05 00000089`2a443c60 00007ff6`2fd7f280     Winfile!OpenOrEditSelection+0xc4 [c:\src\github\microsoft\winfile\src\wfcomman.c @ 630] 
06 00000089`2a445540 00007ff6`2fdf2d44     Winfile!AppCommandProc+0x7d0 [c:\src\github\microsoft\winfile\src\wfcomman.c @ 964] 
07 00000089`2a44b630 00007ffa`78271504     Winfile!FrameWndProc+0x11f4 [c:\src\github\microsoft\winfile\src\winfile.c @ 1031] 

I see the same behavior on WinFile on NT 3.1.

Current directories in Windows are a bit of a frustrating mess. The system allows a file open relative to an existing file handle when opening down the tree, but opening up the tree requires parsing strings. That means each process current directory consists of a handle (used to open foo) and a path (used to open ..\foo.) That in turn means that if a process has a current directory, it is not tolerant to that directory being renamed, or its path will become stale. So, current directory handles are opened without FILE_SHARE_DELETE, ensuring that the string path is in sync with the handle, which creates the behavior here.

I haven't looked into what it would take to avoid changing current directories. It is possible to construct fully qualified paths and always operate on them, avoiding the need to tell Win32 about any current directory. Doing that implies firstly finding all of the code paths that aren't using fully qualified paths, then updating them to be fully qualified.

from winfile.