We use NFS-mounted /home directories; the Properties dialog for desktop
launchers is broken for us.  We see the same behaviour using both NFS3
and NFS4.

If you select Properties for a desktop launcher and choose the
"Launcher" tab, the dialog closes after a delay of a second or so.
All indications are that there is no crash or error per se (no
processes die, nothing's written to .xsession-errors), the dialog just
closes.

The same thing happens to a launcher that's copied from the Desktop
folder to the home directory itself, or to a subdirectory under it -
you can open a Nautilus browser window to view "Home" (or navigate
there via the "Filesystem"), open the Properties dialog for the
launcher, select the Launcher tab and the dialog closes.

Oddly, this bug does NOT affect NFS mounts in general - as a test I
mounted a second instance of server:/home at /mnt using the same mount
options and was able to navigate to it and display the launcher's
Properties dialog, and select and edit the Launcher tab without any
problems.

We've also encountered this bug on Ubuntu 8.04, which uses Nautilus
2.22.5.1 (Ubuntu bug #224642), but not under earlier versions (e.g.,
Ubuntu 6.06, which uses Nautilus 2.14.3).  While it's not serious in
the greater scheme of things, it is a potential "show stopper" for
our NFS client desktops that's blocking their migration to a newer
release, be it Debian or Ubuntu.


John.

Hi,

While investigating other issues I've uncovered a little more
information which relates to this bug, and which may offer a a
workaround for some users.

I've been testing using a "sandbox" LAN connected to an OpenVZ instance;
because OpenVZ doesn't support kernel-mode NFS I've been using Debian
Lenny's unfs3 package.  In this environment, the desktop launcher
properties window works fine.

The main documented difference between using unfs3 and the kernel-mode
server is that unfs3 doesn't support locking, so it looks like this may
well be a locking issue: if you wanted to confirm, try mounting /home
using the kernel mode server, but with the "nolock" option to disable
locking.

This isn't an option for us in production environments because we need
locking, but it may help some people and may help isolate the underlying
issue.

Regards,



John Pearson

Le mercredi 25 février 2009 à 09:34 +1030, John Pearson a écrit :

Sorry for the late reply, but I couldn’t think of anything that causes
that and I don’t have a setup to reproduce that.

First, it would be nice if you tried nautilus 2.26 from unstable, but I
don’t think this is really fixed in this version if this was not in
2.22.

If the bug still happens, you’ll need to debug it, by finding what call
or signal is causing real_destroy (in fm-properties-window.c) to be
invoked.

Cheers,

Hey John,

this is an old bug.

Could you please still reproduce this issue with newer nautilus version
like 3.4.2-1+build1 or 3.8.2-3 ?

thanks
regards
althaser