Reconnecting to session causes duplicate drive entries in fuse fs

[matt335672]

First time I connect, I get remote drives as expected in ~/thinclient_drives :-

$ ls ~/thinclient_drives/
J:  P:  R:  S:  T:  U:

If I disconnect and reconnect immediately, these drives get duplicated, according to ls:-

$ ls ~/thinclient_drives/
J:  J:  P:  P:  R:  R:  S:  S:  T:  T:  U:  U:

Interestingly this duplication is not visible in the GNOME file manager on CentOS.

I've had a look at the code, and it seems the duplication is happening as the fuse inode cache is never cleared. When the user reconnects, the shared drives are being set up again in the fuse inode cache.

If the user reconnects with the same drives, the only visible effect is the drive letter duplication. If however the user reconnects from a differently configured Windows client, the drives may have different letters and/or device numbers. Trying to access missing drives causes the application issuing the access request to hang.

The safest thing is to clear down the fuse inode cache on a disconnect. At this point the fuse filesystem is unmounted anyway.

There's a stub routine in chansrv_fuse.c called xfuse_deinit_xrdp_fs() which is supposed to do precisely this, but has never been implemented. This PR adds an implementation and moves the call to the routine until after the fuse system has been unmounted, so that we can be sure nothing in the inode cache is relevant any more.

Does anyone have any idea why xfuse_deinit_xrdp_fs() was never implemented?

[metalefty]

Good catch. I'm not sure why deinit was not implemented.