On 01/04/13 04:18 PM, [email protected] wrote:
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? :)
Why not just replace your Windows server and switch your client(s) to
Linux? It's probably a lot less work. If you have a program that you
must use that only runs on Windows, try wine or a virtual machine.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
