Folder is locked when expand the folder in left hand side

[ScottHollows]

Issues
If you expand a folder in File Manager using the left hand side
/ folder view area - the folder becomes locked so you can not rename the folder using Windows Explorer

The folder remains locked even if you change to look at another drive.

You have to exit File Manager in order to release the lock.

This locking behaviour doe not occur if you expand the folders in the right hand side (File list area) rather than the left hand side

Expected Behaviour / Change Request
I do not see a reason to lock the folder at all and at very least any folder locks should be released if you make the file least change to another drive

I might be wrong, but I do not recall this occuring with earlier versions of File Manager going back to Windows 3, NT, 2000 days

Please consider removing this folder lock - and preferabley other locks that occur in other situations

Environment
File Manager 10.2.0.4
Windows 10

[schinagl]

Odd! Can reproduce.

[malxau]

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.