shared folder still shared even if recreated after deletion

On Saturday 18,July,2009 02:58 AM, John Baptist wrote:
> To reproduce, on Karmic 9.10 Alpha 2:
>
> 1. Create a new folder.
> 2. Select Sharing Options from its menu.
> 3. Turn on sharing. (At this point samba may install, if you haven't shared before.)
> 4. The sharing emblem appears on the icon. Okay.
> 5. Now delete the folder.
> 6. Now create a new folder with the same name.
> 7. It still has a sharing emblem, at what is more, is still shared! I expected that it would be a new, unshared folder.
It's a new folder, yes. But it's still shared.

> Proposed solution: unshare folders when deleted, and possibly also when
> moved/renamed.
I believe there isn't a way to detect when folders are deleted, moved,
or renamed in Nautilus, due to shortcomings in its extension interface
at the moment. I'll mark this as affecting Nautilus as well.

  affects ubuntu/nautilus-share
  status confirmed
  importance wishlist

  affects ubuntu/nautilus

A workaround that could be implemented in nautilus-share code would be
to detect whether the path exists when loading the list of shares, and
deleting the share if the path does not exist. However, this could cause
issues for shares in certain mountpoints which have not been mounted yet
when Nautilus loads.

The best way would be for Nautilus to have some manner of allowing
plugins to hook onto events such as deletion/renaming of files and folders.

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

Thanks for your bug report. This bug has been reported to the developers of the software. You can track it and make comments here: http://bugzilla.gnome.org/show_bug.cgi?id=589141

upstream rejected the nautilus task, saying that this is a nautilus-share issue.

talked too soon, was re opened.

It actually is a nautilus-share issue since Nautilus doesn't do anything with sharing. Nautilus-share could use a file monitor on the shared folder to see if it's deleted or check the mtime on the folder, or something. My terminal was just being slow and I think I hit back and resumbited it or something. Fixing it now.

On Tuesday 21,July,2009 12:29 AM, A. Walton wrote:
> It actually is a nautilus-share issue since Nautilus doesn't do anything
> with sharing. Nautilus-share could use a file monitor on the shared
> folder to see if it's deleted or check the mtime on the folder, or
> something. My terminal was just being slow and I think I hit back and
> resumbited it or something. Fixing it now.
>
On the surface, it's a nautilus-share issue alone, but I'd like to ask
you to look deeper. The reason I marked Nautilus as affected as well was
due to the deficiencies in its plugin interface. Specifically, Nautilus
lacks a method for plugins to hook onto events such as deletion of files
and folders in its plugin interface.

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

You can open an upstream bug to request such an interface, but this is still a bug in nautilus-share; it's perfectly capable of checking itself without Nautilus' help (as many other plugins already do).

On Tuesday 21,July,2009 01:04 AM, A. Walton wrote:
> You can open an upstream bug to request such an interface, but this is
> still a bug in nautilus-share; it's perfectly capable of checking itself
> without Nautilus' help (as many other plugins already do).
>
With what, a timer?

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

I'm not sure you can solve this by extending the Nautilus plugin interface. For example, what if the file is deleted by another tool (e.g. rm)? Then Nautilus would have no idea about it, nevertheless nautilus-share should still consider the file un-shared.

Here's my idea (please keep in mind that I'm a newbie here and don't know anything about the internals of Nautilus, GNOME, or nautilus-share other than what I've read here, so I apologize if this is nonsense):

Right now, nautilus-share keeps track of which files are shared by their path, I think; that's what gives rise to the current bug, when two different files have, at different times, the same path. What if instead of this, we had a hidden file inside each shared folder, say .nautilus-share-info, which contained some unique ID. All IDs corresponding to currently shared folders are kept in nautilus-share's configuration, ~/.config/nautilus-share or whatever. Nautilus looks in each folder, if it has a .nautilus-share-info, it pulls up the corresponding line from its config and sets up shares accordingly. So, if you delete the folder, you delete the hidden file, too, and no other folder will have the same ID.

Or, g_file_monitor().

test for existence, if it doesn't exist, unshare (obviously). if it does
GFileMonitor *monitor = g_file_monitor (the_shared_directory, ...);
g_signal_connect (monitor, "changed", monitor_cb, ...);
...
static void
monitor_cb (GFileMonitor *monitor, GFile *file, GFile *unused, GFileMonitorEvent event, gpointer user_data)
{
  switch (event)
   {
    case G_FILE_MONITOR_EVENT_DELETED:
       unshare folder
       break;
   }
}

Or the inotify/fam/fsnotify/other file monitoring APIs in your language binding, or if you're really desperate (read: don't be this desperate; g_file_monitor() has a polling backend for desperate, no-native-file-monitoring platforms), check on startup and poll. This will work even if the folder is rmdir'd.

Ah thanks, that would work. The .nautilus-share-info idea does seem
rather appealing as well. I'll give both of them some consideration.

  affects ubuntu/nautilus-share
  status triaged

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

It seems to me that this bug is likely a security problem, as the user could inadvertently share information that was supposed to be private. Furthermore, it is clearly unexpected, inconsistent behavior that is confusing and partially negates the benefit of having a sharing GUI at all. So, I disagree that this should be labeled Wishlist priority. This is definitely a bug, possibly a serious one, not a frivolous feature request.

Please reconsider the assigned priority.

Another thought:
Could this problem be solved with extended attributes? Nautilus-share could add an extended attribute to each shared folder, which would contain a unique identifier, which would map into its list of known shared folders? This, it seems, would be a more reliable solution than tracking files by path and would prevent the kind of confusion demonstrated in this bug and others like it.

Of course, extended attributes aren't enabled by default in Ubuntu, but that's easy to fix.

Setting to triaged as per comment #12 [pff.. lazy hyperair ;p ]

Sorry, can you explain it what sense is this bug "triaged"? In my opinion it is still "confirmed."