On Thu Oct 5 09:29:00 2023 +0000, Zebediah Figura wrote:
I don't think we want this kind of hack in Wine.
Allowing for manual configuration outside of wine.
What does this mean?
Well, as it stands now, if we have an application that relies on wnet API to connect/disconnect remote disks, the application will fail no matter what, as WNetAddConnection() and WNetCancelConnection*() will error out.
(#) If we then go to ~/.wine/dosdevices and setup a new drive sym-linked to some remote FS mounted in ~/.wine/dosdevices/unc/*, we still cannot get around the failures in WNet* api.
While, this sort of work-around is not perfect, in a way it is a success-stub rather than a fail-stub, and at least it allows the application to proceed onto the access phase (read/write/...), and either work (if manual step (#) was completed), or fail unable to do i/o.
It's understood that, the proper way would be to utilize the WNet provider tables and to actually implement a provider that will always succeed on connecting/disconnecting a network drive.
But the latter is a much bigger change, which may be worth it, had there been a need for something more than just a SUCCESS-STUB.