After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 576773 - Unable to view files in Windows shared folder
Unable to view files in Windows shared folder
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Backend: Win32
2.14.x
Other Windows
: Normal normal
: ---
Assigned To: gtk-win32 maintainers
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2009-03-25 21:48 UTC by sriesch
Modified: 2018-02-10 03:28 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description sriesch 2009-03-25 21:48:43 UTC
Please describe the problem:
Using File > Open, one can browse to a shared folder on another Windows machine, but cannot see any of the files in that folder.  (Uncertain if this is a bug or a feature request, assuming it's probably a bug.)  If the file is manually copied in Windows to a local folder, it can then be opened fine.

Steps to reproduce:
1. On another Windows (XP Pro if it matters) machine, create a shared folder and place a .jpg file in it.  On this machine, verify that it can be accessed via My Network Places.  
2. From the Menu Bar, select File > Open.  In the Places frame, double-click on the Desktop icon.  In the center frame, double-click on the shared folder.  Note that the .jpg is not in th elist of files to be opened. 
 


Actual results:
Unable to see the filename in teh list, thus unable to open a file.

Expected results:
Expect that I would be able to see and double-click on the .jpg file to open it.

Does this happen every time?
Yes.

Other information:
In the list of files for the shared folder, there is a single item called "target.Lnk" (rather than the expected .jpg file or the .exe file in the same shared folder).  If you double-click on that, you get a GIMP Message "Opening 'C:\Documents and Settings\Rex Dart\Desktop\temp shared on primary PC (Primary)\target.Lnk' failed: Unknown file type".  Also, just in case it matters, the filename has spaces in it ("cumulus clouds 1.jpg").  This is happening on a pair of Windows XP Pro machines.
Comment 1 Tor Lillqvist 2009-03-27 22:42:45 UTC
Why do you expect to see files that are located on a share on another machine in your Desktop folder?

Type the UNC path to the share into the Location field of the File:Open dialog and press enter, and you should see the share's contents. (I.e. type something like \\server\share\ )

Yes, ideally there should be a similar way to the "My Network" in Microsoft's file selection dialog to open files on the network, with browsable servers and listing of shares on a server. But that does not exist yet. 
Comment 2 sriesch 2009-03-28 18:25:47 UTC
>Why do you expect to see files that are located on a share on another machine
in your Desktop folder?
  (To clarify, the files are not in the Desktop folder, they are in a subfolder in the Desktop folder.  That subfolder is mapped to the actual folder on another machine.)
  I expect to be able to see and open the files in this folder because I assumed they would not be treated any differently than any other files.  For example, I can see and open them without problems using File > Open in both Paint Shop Pro and Adobe Photoshop Elements, just not GIMP.

>Type the UNC path to the share into the Location field of the File:Open dialog
and press enter, and you should see the share's contents.
  Thanks, that works as a workaround if I already know (or want to go searching for) the filename(s) in the folder, although of course it would be nice to still be able to browse normally as is done with all other files and folders.

>Yes, ideally there should be a similar way to the "My Network" in Microsoft's
file selection dialog to open files on the network, with browsable servers and
listing of shares on a server. But that does not exist yet.
  If this needs to be converted from a bug report to a feature request, let me know what I need to do to make this happen.
Comment 3 Matthias Clasen 2018-02-10 03:28:31 UTC
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.