GNOME Bugzilla – Bug 161797
Save as... fails in win32 when curdir is on server
Last modified: 2005-04-05 11:09:39 UTC
Open an image file through windows explorer into Gimp 2.2.0 which has a location of the form \\server\service\path\to\file. Perform a File->Save As... Error that occurs: Save Image: gimp-2.2.exe - Application Error The instruction at "0x009e97d8" referenced memory at "0x0000018d". The memory could not be "written". Click on OK to terminate the program. Click on CANCEL to debug the program. If the \\server\service location is mapped to a drive and opened through explorer through said drive, error does not occur. This may be a problem with GTK+ rather than Gimp, since it seems to be a file dialog problem.
Most probably a GTK+ problem. Did you check if it has been reported against GTK+ already?
Re: Comment #1 Yes, no bugs found with criteria: gtk+ AND win32 AND keywords: save I figured it was a GTK+ problem, but since I experienced it in The Gimp and don't have any other GTK+ apps on my system, I can't test that. And I didn't want to jump to any conclusions. If anyone is sure about this being a GTK+ problem and not a Gimp problem, they should change the product.
How exactly can this problem be reproduced? When does the crash occur? While preparing the file selection dialog, while using it, when actually loading the file?
Re: Comment #3 On a windows (ie: samba) share, create an image file... let's say it is \\server1\files\pics\pic.png You must use windows explorer to open the file because the fileopen dialog has no capacity to open the \\server1\files\pics folder, since it is not based on a root drive (ie: C:, D:, etc). Once the file is open, choose file->save as... The program immediately crashes without opening the Save As... dialog with the aforementioned error message (original report). My guess is that the filesaveas dialog tries to open a default directory, which is the image's current directory (in this case: \\server1\files\pics ). Since the dialog has no capacity to show samba-type shares, it crashes... hence I believe it to be GTK+, but can't be sure without testing in a different program.
I am not entirely sure if GIMP is doing the wrong thing here but then, I don't see how we could know beforehand that the file-chooser won't be able to handle this URL. Reassigning to GTK+. Let's see what the GTK+ developers think about this.
*** Bug 161841 has been marked as a duplicate of this bug. ***
We are getting quite a few of these bug reports now that there's a binary installer for GIMP 2.2. Any advice on how we could workaround this problem from within GIMP would be very much appreciated. Of course a fix in GTK+ would be even better. Would upgrading to GTK+-2.6.0 perhaps solve this problem?
*** Bug 161939 has been marked as a duplicate of this bug. ***
(Bug is not assigned correctly, reassigning to component owner (gtk+ win32 maint))
I do not believe the problem is with GTK, but is a problem with GIMP. I uninstalled GIMP 2.2, I left GTK 2.4.14, reinstalled GIMP 2.0.5 and I am able to open and save, including to network drives. This leads me to believe that it is a problem with GIMP.
Well, it's known that the gtk file selector doesn't support UNC paths (bug #137874), in the sense that there isn't any code in it to handle UNC paths, so I have assumed there probably are bugs. I didn't know that it causes crashes, though.
About comment #10: GIMP 2.0.x doesn't use the new GtkFileChooser widget so it isn't surprising that it isn't affected by this problem.
About comment #11, the GtkFileChooser and related stuff (GtkFileSystemWin32) doesn't have any code to handle UNC paths eiter. Aparently in the old GtkFileSelector they still kinda work, but in GtkFileChooser cause a crash. This is of course unacceptable, and will be fixed. After the winter solstice festivities.
*** Bug 161861 has been marked as a duplicate of this bug. ***
Can reproduce with testfilechooser, when current directory is an UNC path.
Fixing this requires UNC path handling improvements both in GTK+ (gtkfilesystemwin32.c) and GLib. Committed the GLib part to HEAD and glib-2-4: 2004-12-30 Tor Lillqvist <tml@iki.fi> (g_path_get_dirname): Handle UNC paths better. Part of fix for #161797. Still working on the GTK+ part.
Fixing this cleanly also required improvements to g_file_test(). stat() is too broken, it doesn't accept corner cases like the root of a share without a trailing slash ('\\server\share') or oddities like '.\'. Turns out GetFileAttributes() works fine, and g_file_test() doesn't need the fancier information that stat() provides anyway. 2004-12-31 Tor Lillqvist <tml@iki.fi> * glib/gfileutils.c (g_file_test): Rewrite the Win32 version to use GetFileAttributes() instead of stat(). stat() is unreliable for corner cases like '\\server\share' or '.\'. Part of fixing #161797. When testing for executability, in addition to the fixed set of executable file name extensions also check the PATHEXT environment variable.
Created attachment 35317 [details] [review] Current diff Here's my current diff. (Also includes fix for the floppy access problem in bug #157820.) testfilechooser now works fine when started in an UNC path. But going to an UNC path with Control-L doesn't work, so there still are things left to do. It would also be a good idea to add the root of any UNC path we come across automatically as a volume. It seems that the folder_hash in gtkfilesystemwin32.c is used for much less than that in gtkfilesystemunix.c. (Was gtkfilesystemwin32.c copied from gtkfilesystemunix.c a bit too early, at a time when the hash ideas were still unfinished?) Presumably should copy the current working from there. Also, the cache hash and equality functions should be case-insensitive. The timeout to check for volume changes seems a bit odd, isn't a separate timeout created each time gtk_file_system_win32_list_volumes() is called? Would presumably be better to have just one timeout running that if needed updates all GtkFileSystemWin32s that are active when it runs. As it is now, shouldn't the timeout be removed in the finalize function?
The actual problem reported here should now be fixed in HEAD. At least when tested with testfilechooser and testfilechooserbutton UNC paths work fine. There is still room for improvement in gtkfilesystemwin32.c, though, especially the folder_hash probably needs enhancement as mentioned in the previous comment. 2005-01-02 Tor Lillqvist <tml@iki.fi> * gtk/Makefile.am (libgtk_target_ldflags): Add -lole32, needed for CoTaskMemFree in get_special_folder() below. * gtk/gtkfilesystem.h: Implement case-insensitive path compare on Win32 using _gtk_file_system_win32_path_compare(). * gtk/gtk.symbols: Add _gtk_file_system_win32_path_compare. * gtk/gtkfilechooserbutton.c (model_add_special) * gtk/gtkfilechooserdefault.c (shortcuts_append_desktop): Use _gtk_file_system_win32_get_desktop() to get correct Desktop folder on Win32. (#144003) * gtk/gtkfilesystemwin32.c: Remove unnecessary includes. Do consider all drives "mounted", including floppies. Trying to inspect the contents of a nonexistent floppy will cause errors later that are handled normally, no need to avoid them completely. Keep the drive type in the GtkFileSystemVolume. Support UNC paths. (#161797) Fix error message capitalizations as in gtkfilesystemunix.c. (gtk_file_system_win32_init): Start one timeout per GtkFileSystemWin32. (gtk_file_system_win32_finalize): Remove the timeout. (get_special_folder): Copied from GLib. (_gtk_file_system_win32_get_desktop): New function, uses get_special_folder(). (gtk_file_system_win32_list_volumes): Don't start a timeout at each call to this function. Don't assume A: and B: are floppies. (gtk_file_system_win32_get_volume_for_path): Don't assume all volumes are drive roots, i.e. support share roots of UNC paths (\\server\share). (gtk_file_system_win32_get_folder): Don't assume errno is set after g_file_test() returns FALSE. It isn't on Win32 (and even on Unix I don't think one should assume anything about errno after g_file_test()). (gtk_file_system_win32_volume_get_is_mounted): Always return TRUE. (gtk_file_system_win32_volume_get_display_name): Don't call GetVolumeInformation() on drives A: or B: if they are removable, as they might then be floppies, causing an unnecessary delay. (#157820) (gtk_file_system_win32_volume_render_icon): Use network icon for unrecognized drive types. (canonicalize_filename, gtk_file_system_win32_parse): Don't get confused by UNC paths. (bookmarks_serialize): Use _gtk_file_system_win32_path_compare() for case-insensitive UTF-8 path comparison. (extract_icon): Use SHGetFileInfo() which is faster than ExtractAssociatedIcon(). Icon extraction is still slow, though, needs work. (win32_pseudo_mime_lookup): Don't use the same icon for all shortcuts or executables. Cache only other file type icons. (gtk_file_system_win32_render_icon): Use network stock icon for remote drives and UNC server share roots. Compare home directory case-insensitively. Do lookup icons also for executable files, after all, it's these files that can have individual icons in the first place. Yes, it can be slow. Needs work. (filename_is_drive_root): Require also the slash after the colon. (filename_is_server_share): New function. (_gtk_file_system_win32_path_compare): New function, does case-folded UTF-8 comparison. * gtk/gtkfilesystemwin32.h: Declare _gtk_file_system_win32_path_compare().
*** Bug 137874 has been marked as a duplicate of this bug. ***
Created attachment 35457 [details] [review] Suggested follow-up patch This patch adds the path_compare and get_desktop members to the GtkFileSystem interface, and the corresponding gtk_file_system_* functions, then uses them where appropriate. For casefolded path comparison on Win32 a table is used that is hopefully close to that used on most NTFS file systems. It is generated by code from the NTFS driver in Linux. The table's size is 128 KB. Some other improvements, for instance in gtkfilechooserentry the auto-completion is now case-insensitive on Win32.
Created attachment 35478 [details] [review] Improved follow-up patch Various improvements. Use the simple one-to-one g_unichar_toupper() in casefolding if not using the upcase table, as Windows's case-insensitiveness for pathnames definitely is of the one-to-one type.
*** Bug 163295 has been marked as a duplicate of this bug. ***
*** Bug 163905 has been marked as a duplicate of this bug. ***
*** Bug 164395 has been marked as a duplicate of this bug. ***
*** Bug 165138 has been marked as a duplicate of this bug. ***
*** Bug 169086 has been marked as a duplicate of this bug. ***
*** Bug 169162 has been marked as a duplicate of this bug. ***
*** Bug 163707 has been marked as a duplicate of this bug. ***
*** Bug 169432 has been marked as a duplicate of this bug. ***