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 301068 - GtkFileChoose on systems with NFS / AFS will hang for 20 minutes+
GtkFileChoose on systems with NFS / AFS will hang for 20 minutes+
Status: RESOLVED FIXED
Product: libgnomeui
Classification: Deprecated
Component: file-chooser
2.10.x
Other All
: High major
: future
Assigned To: Federico Mena Quintero
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2005-04-18 14:48 UTC by drube
Modified: 2005-05-10 01:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch for gtkfilechooserdefault.c and gtkfilesystemunix.c (5.77 KB, patch)
2005-05-03 01:50 UTC, Federico Mena Quintero
committed Details | Review
Patch to fix GtkFileSystemGnomeVFS in libgnomeui (7.82 KB, patch)
2005-05-10 01:58 UTC, Federico Mena Quintero
committed Details | Review

Description drube 2005-04-18 14:48:35 UTC
GtkFileChoose inspects the whole file tree up to root point. Having mounted
external disks via Transarc's AFS under /afs produces an interrupt of more than
20 minutes for a single file open because every AFS cell around the world is
inspected before the widget comes up. To avoid this GtkFileChoose must not 
inspect /afs. The same should be done for /net.
Comment 1 Michael Schumacher 2005-04-18 14:55:50 UTC
If you already identified this as GtkFileChoose, why did you file it as a bug
against GIMP?
Comment 2 drube 2005-04-18 15:12:23 UTC
because I think either GIMP or GTK could be modified because of this.
Comment 3 Sven Neumann 2005-04-18 15:43:10 UTC
Please specify the version of GTK+ that you are using so that we can properly
reassign this bug report.
Comment 4 drube 2005-04-19 07:13:07 UTC
sorry! the version is 2.4.14
Comment 5 Raphaël Quinet 2005-04-19 15:47:08 UTC
Re-assigned to gtk+ (and sorry for the CC: noise)
Comment 6 Federico Mena Quintero 2005-04-19 18:56:31 UTC
Just to refresh my memory, can you please confirm these statements:

1. Doing stat("/afs", &statbuf) is fine.

2. Doing opendir("/afs") and then readdir() is *not* fine.
Comment 7 drube 2005-04-20 12:14:42 UTC
both seems to work. What happens on 'open file' in gimp ist listed 
below: Every entry of a directory ist treated with stat64. The time 
consuming actions are the lines with 'lost contact'. I don't see a 
logical reason why one must inspect every entry of each parent 
directory (!!) with stat64.

That should be done if I select this direcory, not before.
The output below is produced with the 'truss' command which lists
every system call

19103:  stat64("/afs", 0xFFBFD4B0)                      = 0
19103:  open("/afs", O_RDONLY|O_NDELAY|O_LARGEFILE)     = 6
19103:  fstat64(6, 0xFFBFD360)                          = 0
19103:  fcntl(6, F_SETFD, 0x00000001)                   = 0
19103:  getdents64(6, 0x00D52E48, 8192)                 = 5072
19103:  getdents64(6, 0x00D52E48, 8192)                 = 0
19103:  close(6)                                        = 0
19103:  time()                                          = 1113998738
afs: Lost contact with volume location server 195.42.214.241 in cell extundo.com
19103:  stat64("/afs/extundo.com", 0x00E1FAA0)          Err#145 ETIMEDOUT
afs: Lost contact with volume location server 128.114.129.14 in cell cats.ucsc.edu
afs: Lost contact with volume location server 128.114.129.18 in cell cats.ucsc.edu
Comment 8 Morten Welinder 2005-04-29 14:10:27 UTC
I am pretty sure 2.6 does not do this.  At least for me, it does not stat
every entry in parent directories.

If you were to navigate to /afs you would still be in trouble with 2.6.  The
only fix for that would be to fake the stat-ing for any entry in /afs (i.e.,
simply pretend it is a 0755 directory).
Comment 9 Federico Mena Quintero 2005-05-03 01:50:34 UTC
Created attachment 45962 [details] [review]
Patch for gtkfilechooserdefault.c and gtkfilesystemunix.c

This patch fixes the stock Unix backend.  A forthcoming patch will fix the VFS
backend.

I committed this patch to the gtk-2-6 and HEAD branches.
Comment 10 drube 2005-05-03 13:09:12 UTC
I tested with 2.6. The problem of 20 minutes+ from 2.4 shrinked
to about 10 seconds. Not so bad but not good.

So I agree Morton that 2.6 does not stat every entry in parent
directories. But his idea to change to 0755 is impossible for 
AFS root path.

Nevertheless: According to bug 302322 a file open lasts too long
for full directories.
Comment 11 Federico Mena Quintero 2005-05-05 18:24:34 UTC
Could you please run 'strace -ttt -f -o logfile.txt gimp', then visit your /afs,
and attach the gzipped strace log to this bug?

Just to confirm:  did you apply the patch I attached, or did you pick up the
latest code in the gtk-2-6 branch from CVS?
Comment 12 Federico Mena Quintero 2005-05-05 18:25:39 UTC
Changing the product/component to libgnomeui/file-chooser since that's what
remains to be fixed for now.
Comment 13 Federico Mena Quintero 2005-05-05 18:26:31 UTC
About comment #11, please massage that command line to be friendly to 'truss' :)
 I basically need timestamps for the system calls and per-thread information.
Comment 14 Federico Mena Quintero 2005-05-06 21:07:32 UTC
I just fixed a leftover problem in the Unix backend (fill_in_mime_type was
stat()ing unconditionally), so you may want to update your GTK+ again.  It's in
the gtk-2-6 and HEAD branches.
Comment 15 drube 2005-05-09 15:25:40 UTC
Applying the patch of comment #9 improves the time for file open
dramatically to ~ one second.

Unfortunately I could install only strace 4.3 under Solaris.
All newer releases refuse to compile because of unknown
POSIX_FADV_* variables. strace-4.3 refused to follow the
gimp child processes of your comment #11. So I'm unable to
send you the log file at the moment.

Replacing the gtkfilesystemunix.c from CVS (comment #14) I get 
the following compiler error:

gtkfilesystemunix.c: In function `gtk_file_system_unix_iface_init':
gtkfilesystemunix.c:324: error: structure has no member named `get_bookmark_label'
gtkfilesystemunix.c:325: error: structure has no member named `set_bookmark_label'
Comment 16 Federico Mena Quintero 2005-05-09 18:00:34 UTC
I'm pretty sure that you took gtkfilesystemunix.c from HEAD and put it into your
2.6 tree.  If that is the case, please grab the same file from the gtk-2-6
branch instead.
Comment 17 Federico Mena Quintero 2005-05-10 01:58:49 UTC
Created attachment 46264 [details] [review]
Patch to fix GtkFileSystemGnomeVFS in libgnomeui

This patch fixes the VFS backend for the file chooser so that it does not
stat() entries under /afs or /net.  With this, the whole bug is fixed.
Comment 18 Federico Mena Quintero 2005-05-10 01:59:18 UTC
I already committed the libgnomeui patch to the gnome-2-10 and HEAD branches, by
the way.