Share emblem does not show on XDG standard directories

[Paul Vandenberg]

If an XDG standard directory, e.g. ~/Documents, ~/Music, or ~/Pictures is shared, the sharing emblem appears just after sharing, but does not appear automatically when loading the view for the home directory upon restart of Nautilus. This is because, when Nautilus Share is told to share a directory, it immediately adds the emblem to the directory.

However, upon a restart of Nautilus, the way Nautilus Share detects which directories to add emblems to is via the Nautilus Info Provider interface. However, Nautilus does not query plugins for information via this interface for XDG standard directories.

As far as I can see, there is no way within the bounds of Nautilus' plugin API to work around this issue in Nautilus Share code. The fix has to be in Nautilus code.

[emorrp1 (emorrp1)]

I can confirm this bug, we've had several people report this in the mint forums. It also affects the properties tab of the shared folder reporting that it's no longer shared, when full access is possible from other machines:
http://forums.linuxmint.com/viewtopic.php?f=166&t=27666

[emorrp1 (emorrp1)]

^^^ Sorry, wrong link: http://forums.linuxmint.com/viewtopic.php?f=166&t=27667

[Chow Loong Jin (hyperair)]

On Mon, 2009-06-15 at 12:27 +0000, Philip Morrell wrote:
> ^^^ Sorry, wrong link:
> http://forums.linuxmint.com/viewtopic.php?f=166&t=27667
>
Thanks for reporting this bug. Could you post the output of the
following commands when the emblem disappears, please?

$ net usershare list
$ net usershare info <share name>

Thanks in advance.

  status incomplete
--
Regards,
Chow Loong Jin (GPG: 0x8F02A411)
Ubuntu Contributing Developer

[emorrp1 (emorrp1)]

According to altair, my bug reporter:
$ net usershare list
documents
$ net usershare info documents
[documents]
path=/home/tester1/Documents
comment=
usershare_acl=Everyone:F,
guest_ok=y

[Chow Loong Jin (hyperair)]

Hmm, this is very strange. Could you get the output of nautilus in a terminal when reproducing this bug?

[emorrp1 (emorrp1)]

It's about to get stranger - Altair details the steps he took:

(1) "Un-shared" my Documents share
(2) Rebooted - just in case
(3) Started nautilus from a terminal and from within nautilus recreated my Documents share. ( share / write / guest = yes )
(4) Logged off and on again
(5) Launched nautilus from a terminal
(6) Looked at Properties > Share to verify that it was still broke

There was no output in the terminal of any kind.

Note: In this particular case the icon was in an "unshared" state but the properties > share state indicated that it was still shared with guest access enabled but "write" was disabled. As I stated in my original post it takes repeated logins before the properties tab is completely cleared of ticked options. And I was able to write from a remote machine

[Chow Loong Jin (hyperair)]

On Tue, 2009-06-16 at 17:35 +0000, Philip Morrell wrote:
> It's about to get stranger - Altair details the steps he took:
>
> (1) "Un-shared" my Documents share
> (2) Rebooted - just in case
> (3) Started nautilus from a terminal and from within nautilus recreated my Documents share. ( share / write / guest = yes )
> (4) Logged off and on again
> (5) Launched nautilus from a terminal
> (6) Looked at Properties > Share to verify that it was still broke
>
> There was no output in the terminal of any kind.
>
> Note: In this particular case the icon was in an "unshared" state but
> the properties > share state indicated that it was still shared with
> guest access enabled but "write" was disabled. As I stated in my
> original post it takes repeated logins before the properties tab is
> completely cleared of ticked options. And I was able to write from a
> remote machine
>
Alright, I see this one. Just to confirm:
      * The emblem issue only happens when attempting to share
        Documents, but not for other random folders (I can reproduce
        this but I can't figure out what's going on)
      * The "write" option appearing disabled but actually enabled is a
        bug in nautilus-share (I have spotted the faulty code and will
        push a patch for this)
      * I still can't reproduce the issue where Properties > Share is
        disabled upon restarting.
--
Regards,
Chow Loong Jin (GPG: 0x8F02A411)
Ubuntu Contributing Developer

[Daniel Morales (danielmorales)]

Hi all

Sorry my intermission, but i already fixed the write option issue in the backend @ another app, if no one is working on it i can clean up my patch and upload it later.

Regards,

Daniel.-

[emorrp1 (emorrp1)]

Daniel: that'd be great thanks, I'm sure altair will test it to check it works (he is following this bug, but just doesn't have lp acc.).

from Altair:
emblem: It will happen to any and all folders not just Documents. I just shared Documents, Pictures, and Videos. Logout - login - share icon lost.
write: that's good news, thanks
properties: The Properties > Share tab being cleared of options is tricky. It doesn't completely vanish at a predictable number of reboots or logins. I can appreciate his difficulty on this one.

[Daniel Morales (danielmorales)]

All right, here is the debdiff that includes the patch.

The package is built at my PPA if anyone want to test it: https://launchpad.net/~danielmorales/+archive/ppa

These are for Intrepid... will upload for Jaunty later.

[Daniel Morales (danielmorales)]

And here is the debdiff for Jaunty.

Package available at my PPA: https://launchpad.net/~danielmorales/+archive/ppa

Hope it helps.

Regards,

Daniel.-

[Chow Loong Jin (hyperair)]

On Tue, 2009-06-16 at 21:18 +0000, Daniel Morales wrote:
> Hi all
>
> Sorry my intermission, but i already fixed the write option issue in the
> backend @ another app, if no one is working on it i can clean up my
> patch and upload it later.
Thanks for your efforts, but I've already fixed that part in the
nautilus-share git packaging repository for Debian (I prefer the use of
strstr, because "Everyone:R/F" can appear anywhere in the string) and
was poking around with the emblem issue for the past few hours.

The results of my tests were that the bug cannot be fixed in
nautilus-share, but resides in the nautilus extensions interface code.
Specifically, the Nautilus Info Provider interface calls the function
provided by an extension for all files/directories except the XDG
standard directories, i.e. Documents, Music, Pictures, etc. If this is
fixed in Nautilus, then the emblem issue would automatically be fixed
without any change in nautilus-share code.

  affects ubuntu/nautilus
  status new
--
Regards,
Chow Loong Jin

[emorrp1 (emorrp1)]

Ok, drifting into the area of speculation here: I seem to remember reading somewhere that there's a package (or even just a util) that deals with the naming of these base folders for internationalisation reasons (if you login with a new language, it'll dynamically rename the folders to account for this change). Could this perhaps be affecting the issue at all, as it's another base-folder specific manipulation tool. If not, no worries, it was just speculation, though you seem to have identified exactly where the issue is.

[emorrp1 (emorrp1)]

Also, I've just noticed that the original bug report was for intrepid. Altair provides these version numbers for his situation:

nautilus 1:2.26.2-0ubuntu2
nautilus-share 0.7.2-4ubuntu1
kernel 2.6.28-11-generic
arch i686 (32 bit)
distro Linux Mint 7 Gloria - Main Edition (based on Jaunty)

[Chow Loong Jin (hyperair)]

On Wed, 2009-06-17 at 11:39 +0000, Philip Morrell wrote:
> Ok, drifting into the area of speculation here: I seem to remember
> reading somewhere that there's a package (or even just a util) that
> deals with the naming of these base folders for internationalisation
> reasons (if you login with a new language, it'll dynamically rename the
> folders to account for this change). Could this perhaps be affecting
> the issue at all, as it's another base-folder specific manipulation
> tool. If not, no worries, it was just speculation, though you seem to
> have identified exactly where the issue is.
>

Could be, but I'm not very sure either, having never poked around
nautilus's code before.

As for the version numbers, it doesn't really matter, I can reproduce
the bug on my system, running a fully updated karmic.

--
Regards,
Chow Loong Jin (GPG: 0x8F02A411)
Ubuntu Contributing Developer

[Daniel Morales (danielmorales)]

Debian Git? aww.. didn't see the change yesterday.

[Chow Loong Jin (hyperair)]

On Wed, 2009-06-17 at 13:46 +0000, Daniel Morales wrote:
> Debian Git? aww.. didn't see the change yesterday.
Sorry, I forgot to push, my bad. Anyway, I noticed that your debdiffs
were for Intrepid and Jaunty. If you feel like doing SRUs for this bug,
go ahead =)

--
Regards,
Chow Loong Jin

[emorrp1 (emorrp1)]

Altair confirms that the emblem bug is only for the base folders e.g. Documents etc.

[Chow Loong Jin (hyperair)]

On Wed, 2009-06-17 at 14:05 +0000, Philip Morrell wrote:
> Altair confirms that the emblem bug is only for the base folders e.g.
> Documents etc.
>

Cool. Anyway, nautilus-share 0.7.2-8 is now in Debian with the patch to
fix the writable option bug. The next autosync round should bring it
into Ubuntu.

--
Regards,
Chow Loong Jin

[Launchpad Janitor (janitor)]

This bug was fixed in the package nautilus-share - 0.7.2-8

---------------
nautilus-share (0.7.2-8) unstable; urgency=low

  * debian/patches/10_fix-writable-detection.patch:
    + Fix parsing of share writability from the output of net (LP: #280480)
  * debian/rules:
    + Add -Wl,-z,defs to LDFLAGS

 -- Ubuntu Archive Auto-Sync <email address hidden> Thu, 18 Jun 2009 08:32:54 +0100

[emorrp1 (emorrp1)]

According to Launchpad Janitor (from archive auto-sync), this bug has been fixed, so status was changed from confirmed to fix released. However the original bug-report dealt only with the emblem issue, so the status should in reality be invalid for nautilus-shares and confirmed for nautilus. I admit it doesn't help that I hi-jacked this thread by forwarding a second, related bug from altair at the same time as confirming this one, when in fact I really should have opened a new bug. I guess the easiest (rather than correct) way to sort this would just be to edit the original bug report to reflect the write issue too.

p.s. thanks for all your help in the rapid resolution of the writable issue though!

[Chow Loong Jin (hyperair)]

On Thu, 2009-06-18 at 20:46 +0000, Pedro Villavicencio wrote:
> ** Changed in: nautilus (Ubuntu)
> Status: New => Fix Released
>
It isn't fixed in the current version of Nautilus in Karmic. Just to
clarify, the issue which affects nautilus is that it does not query the
extensions via the info provider interface for xdg standard directories,
such as Documents, Music, Pictures.

  affects ubuntu/nautilus
  status confirmed

--
Regards,
Chow Loong Jin (GPG: 0x8F02A411)
Ubuntu Contributing Developer

[Sebastien Bacher (seb128)]

Thank you for your bug report. The issue is an upstream one and it would be nice if somebody having it could send the bug the to the people writting the software (https://wiki.ubuntu.com/Bugs/Upstream/GNOME)

[emorrp1 (emorrp1)]

bug filed: http://bugzilla.gnome.org/show_bug.cgi?id=586733

[Sebastien Bacher (seb128)]

Thank you for sending the bug to GNOME

[Sebastien Bacher (seb128)]

the bug is assigned to nautilus share thereis no need to add the component in the titme

[Sebastien Bacher (seb128)]

the bug is assigned to nautilus share thereis no need to add the component in the title

[Sebastien Bacher (seb128)]

emblems have been deprecated in recent nautilus versions, closing the bug as it's obsolete