Bug 525875 - DNSSD-announced services missing from Nautilus Network window, despite being discovered by Avahi
Summary: DNSSD-announced services missing from Nautilus Network window, despite being ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: gvfs
Version: 17
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Tomáš Bžatek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-26 15:03 UTC by James
Modified: 2015-03-03 22:41 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-05-22 19:35:31 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 597060 0 None None None Never

Description James 2009-09-26 15:03:42 UTC
Description of problem:
Under certain conditions (the circumstances of which are not currently clear to me), hosts and services announced on DNSSD do not always show up in the Nautilus Network window. This sometimes happens when a new service is configured on the network while Nautilus is running. Restarting Nautilus does not solve the problem, the affected services remain missing until the network connection is re-negotiated. This does not seem to be a problem with Avahi itself, since the correct services always show up in avahi-discover.

Filed under gvfs, as I assume its the gvfs-dnssd component that provides this service to Nautilus.

Version-Release number of selected component (if applicable):
nautilus-2.26.3-3.fc11.x86_64
avahi-0.6.25-3.fc11.x86_64
gvfs-1.2.3-12.fc11.x86_64

How reproducible:
Sporadically.

Comment 1 James 2009-09-29 17:06:23 UTC
It's happened in this session, which was a clean start-up:

$ gvfs-ls network:///
smb-root

vs.

$ avahi-browse _sftp-ssh._tcp
+ virbr0 IPv4 SFTP File Transfer on rhapsody                SFTP File Transfer   local
+ eth0 IPv4 SFTP File Transfer on pyamp2                  SFTP File Transfer   local
+ eth0 IPv4 SFTP File Transfer on pyamp5                  SFTP File Transfer   local
+ eth0 IPv4 SFTP File Transfer on pyamp4                  SFTP File Transfer   local
+ eth0 IPv4 SFTP File Transfer on pylecream               SFTP File Transfer   local
+ eth0 IPv4 SFTP File Transfer on pyamp3                  SFTP File Transfer   local
+ eth0 IPv4 SFTP File Transfer on pyamp6                  SFTP File Transfer   local
+ eth0 IPv4 SFTP File Transfer on pyamp1                  SFTP File Transfer   local
+ eth0 IPv4 SFTP File Transfer on rhapsody                SFTP File Transfer   local

Killing gvfsd-network and gvfsd-dnssd seems to bring back the correct list of machines.

Comment 2 James 2009-12-07 23:23:42 UTC
One way I've found to reproduce this is to pull the plug on the remote machine. On my F12 notebook, it does NOT disappear from either network:/// or avahi-discover. When I restart the avahi service, it's gone from avahi-discover but remains in network:///, until gvfsd-network and gvfsd-dnssd are killed.

Comment 3 James 2010-05-20 13:50:18 UTC
Re-plugging all network connections on the local machine seems to trigger gvfsd-network to synchronise with Avahi. For some reason the former seems to fall out of sync with the latter.

Comment 4 James 2010-07-26 09:57:51 UTC
Still present in Fedora 13. My typical reproduction case is:

1. Have my work machine running.
2. Bring in laptop, attach to network and resume from sleep.
3. Notice work machine present in laptop's network:///
4. Notice laptop is absence from work machine's network:///, but shows up in avahi-discover OK.

Killing gvfsd-network, gvfsd-dnssd and restarting Nautilus no longer seems to work. However, re-negotiating the network connection by clicking on "System eth0" under nm-applet does cause new hosts to appear.

Comment 5 Bug Zapper 2011-06-02 17:40:08 UTC
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 6 James 2011-12-03 13:39:59 UTC
Still present in Fedora 15, gvfs-1.8.2-1.fc15.x86_64

Comment 7 James 2012-05-08 23:29:41 UTC
This continues to be the case in Fedora 17. Doesn't refresh until the network interface is reconnected. gvfs-1.12.2-1.fc17.x86_64

Comment 8 James 2013-05-22 19:35:31 UTC
No effort at fix in F17 appears to have been made. Will close and test in F19, opening a new bug if it persists.


Note You need to log in before you can comment on or make changes to this bug.