When trying to copy files to/from a Windows file server from/to another
Windows machine, at times the Windows Explorer application will just
hang. This could be due the server being less than responsive, or some
other reason. It ends up being really annoying as Explorer just stops
responding due to, presumably, being stuck waiting for a response from
the remote server. There are times when just clicking a file will then
cause Explorer to hang, as though its requesting info for the file and
not getting a response.
Every time I run into this, I think, why wouldn't this all be threaded?
Why would a background thread do all the network communications
asynchronously so that the UI didn't freeze up like this? Then I think,
why not just write a simple CIFS/SMB client which is asynchronous and
which doesn't hang due to the remote server not responding. Also,
something that doesn't send any unnecessary requests. i.e., give me the
list of files, let me pick which ones to copy, and copy. Don't request
any additional info about the files (as I think happens when you
right-click a file).
But why write a CIFS/SMB client, when Samba has already done it? I know
Samba is intended for Linux, allowing Linux users to interoperate with
Windows. But has anyone ever attempted building/using the Samba code on
Windows? Could Samba be used to do the protocol stuff in a Windows
application?
Seems like there's no reason to re-invent the wheel and dig through the
MS protocol documentation, if Samba could be re-used for this purpose.
Does this seem feasible? Or is this ill-advised? :)
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
