vscode: File writes can hang when write locks are not cleared up

@alexrs84 I found it! I totally missed an issue when implementing this locking and here is what happens:

• resource locks are stored per file handles in a map and a file handle is just a number
• we always have a sequence of open, write(n), close calls for each file write
• in open we store the lock for the handle and in close we dispose it

And here is the race condition:

• we call fs.close(fd) and then try to remove the lock from the map with that fd
• however, after fs.close(fd) the operating system is free to assign that exact same fd to the next write call for any othe file
• as such, there is a slight chance that our lock for fd is being replaced with a new lock after fs.close(fd) but before we get a chance to clean up the lock

In code (a bit simplified):

async close(fd: number): Promise<void> {
    try {
        return await Promises.close(fd);

        // !!!!! The `fd` is free now and can be assigned by the OS for another `write` operation !!!!!!

    } catch (error) {
        throw this.toFileSystemProviderError(error);
    } finally {

        // !!!!! here we wrongly assume that the map for file locks
        // is still associated with our file, but in fact it is the next
        // write operation's file we dispose here
        // As such, the original file lock hangs as never getting 
        // disposed

        const lockForHandle = this.mapHandleToLock.get(fd);
        if (lockForHandle) {
            this.mapHandleToLock.delete(fd);
            lockForHandle.dispose();
        }
    }
}

Thanks a lot for the patience and the help 🙏

dev console: slower-vscode-app-1645090832302.log

full stdout: slower-vscode-insiders-stdout.log

Regarding the SMB locks earlier, from what I understand smbstatus -l shows all opened resource handles (that includes resources opened with flags: r, r+, w, w+) that haven’t yet been released - regardless of any oplock/flock, if any.

I notice in src/vs/platform/files/node/diskFileSystemProvider.ts that when writing:

• if windows: manual truncation, then fs.open(...) with “r+” flag
• else: fs.open(...) with w flag

So the w file handle should show for me in the smbstatus -l list as a RDWR lock like

Locked files:
Pid      DenyMode   Access      R/W        Oplock      SharePath        Name            Time
--------------------------------------------------------------------------------------------------
25136    DENY_NONE  0x20087     RDWR       NONE        /mnt/vo.../www   test/Test.txt   We... 14:19:02 2022

and should remain while vscode is still running in the busy state, unless the previous doSave() finished up to and including the fs.close() call to release the previous w (RDWR) handle - so maybe it could help pinpoint what’s hanging, like maybe it stops executing after the fs.close() but before the internal lock dispose(). Probably isn’t hanging during fs.open() or fs.write() because the former RDWR lock in SMB no longer exists, it was released.

Anyway, let me know if you need any more --verbose logs.