GNOME Bugzilla – Bug 329203
FileChooser does not allow selecting shares on a given host
Last modified: 2018-02-10 03:42:53 UTC
Please describe the problem: On Windows, when in the file explorer writing the the following syntax: \\foo where foo is the name of a host, the user will be shown all the so called shares that the host exports. This does not work in the gtk file chooser. I.e. if foo exports the shares "bar" and "baz", then it is legal to write in the location bar: \\foo\bar or \\foo\baz but writing \\foo gives the error message: Error getting the information for \foo . The system can not find the file specified. Steps to reproduce: 1. On host foo export two shares bar and baz 2. On another host try run the file chooser, press Ctrl-L, and write \\foo Actual results: The error message: Error getting the information for \foo . The system can not find the file specified. appears Expected results: I expect to get a listing that includes "bar" and "baz". Does this happen every time? Yes. Other information: Gtk ver 2.8.9 with corresponding glib.
Fixind out the list of shares exported from a host is not trivial (it would require a totally different API than listing a local folder) and potentially could be time-consuming (having to wait for timeouts if there is a typo in the host name) with the UI blocked during that time. Getting it Right providing an optimal user experience would require significant amounts of hairy code, maybe with the actual share enumeration running in a separate thread, or using some asynchronous API, or whatever. Patches welcome...
Heres some info on enumerating shares on a machine using the NetShareEnum api, from msdn: http://blogs.msdn.com/adnanb/archive/2007/05/10/enumerating-shares-on-a-machine.aspx ....Of course this doesn't sort any of the other issues raised but just shows a possible starting point.
Note: Of course this is only for Windows shares on windows, but is in line with what people expect to happen there.
*** Bug 647092 has been marked as a duplicate of this bug. ***
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.