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. ***