This is kind of confusing.. you're saying that importing /music does not import any subfolders, but importing /music/artist does?

You also imply that this used to work for you.  If so, which version was the last one you used where this worked?

(In reply to comment #1)
> This is kind of confusing.. you're saying that importing /music does not import
> any subfolders, but importing /music/artist does?
> 

OK. I played around this a bit and now I've found some pattern to it. 

/music is a mounted folder. It seems that RB does not like it when in the import folder dialogue, a mounted directory is selected. Otherwise the problem does not exist, even when folders *inside* mounted volumes are selected.

So, to reproduce the problem, 

1. Mount a volume to a folder /mnt/x
2. Go to import folder and select /mnt/x

RB does nothing. But no problems occur when /mnt/x/y is selected.


> You also imply that this used to work for you.  If so, which version was the
> last one you used where this worked?
> 

I think it was broken first when the watching music library with FAM feature was introduced (0.9.2?)

What's probably happening here is that the gnome_vfs_directory_visit call is finding the lost+found directory on your filesystem, then stopping because it can't read the directory.  You could temporarily do 'sudo chmod 755 /music/lost+found' to test this.  What filesystem are you using?  I think some don't have lost+found directories.

If this turns out to be the problem, I'll reassign this bug to gnome-vfs and ask that gnome_vfs_directory_visit either ignore lost+found altogether (probably not a good idea) or at least ignore errors when attempting to access it.  Maybe there should be an option to ignore permission problems entirely.

*** Bug 343850 has been marked as a duplicate of this bug. ***

Confirming as a bug.

(In reply to comment #3)
> What's probably happening here is that the gnome_vfs_directory_visit call is
> finding the lost+found directory on your filesystem, then stopping because it
> can't read the directory.  You could temporarily do 'sudo chmod 755
> /music/lost+found' to test this.  What filesystem are you using?  I think some
> don't have lost+found directories.
> 
> If this turns out to be the problem, I'll reassign this bug to gnome-vfs and
> ask that gnome_vfs_directory_visit either ignore lost+found altogether
> (probably not a good idea) or at least ignore errors when attempting to access
> it.  Maybe there should be an option to ignore permission problems entirely.
> 

Filesystem is ext3 and now I can confirm that l+f permissions was the problem here. The above suggestion solved the problem. l+f was inaccessible to others except root before the change. Thanks.

OK, thanks for confirming that.  I'm moving this bug to gnome-vfs, since we'll need some changes to gnome_vfs_directory_visit to get this to work.  

The problem is that it stops when it hits a directory it can't read.  When using it on the root of an ext2 or ext3 volume, it never provides any results at all, because the first directory entry is lost+found, which is owned by root and has 0700 permissions.

I can see a few different solutions to this:
- have gnome_vfs_directory_visit completely ignore permission problems
- add a GnomeVFSDirectoryVisitOptions flag to tell it to ignore permission problems
- just ignore permission problems for directories called lost+found

I don't think it's useful to have gnome_vfs_directory_visit stop altogether when it encounters a directory it can't read, except when that directory is the one specified by the caller.  It doesn't return any information on which directory caused the problem.

The GnomeVFSDirectoryVisitFunc should set *recurse to FALSE and return TRUE if the GnomeVFSFileInfo provides GNOME_VFS_FILE_INFO_FIELDS_ACCESS fields, has a GNOME_VFS_FILE_TYPE_DIRECTORY type and its access field does not have GNOME_VFS_PERM_ACCESS_READABLE, i.e.

static gboolean
my_visit_func (const char *rel_path,
               GnomeVFSFileInfo *info,
               gboolean recursing_will_loop,
               gpointer data,
               gboolean *recurse)
{
  if (info->type == GNOME_VFS_FILE_TYPE_DIRECTORY &&
      (info->valid_fields & GNOME_VFS_FILE_INFO_FIELDS_ACCESS) &&
      !(info->permissions & GNOME_VFS_PERM_ACCESS_READABLE)) {
     /* skip unreadable directories */
     *recurse = FALSE;
     return TRUE;
  }

/* ... your code ... */
}

I'll soon pick up my work on the documentation again and provide a similar example.

I've fixed this in rhythmbox with the above checks (and the addition of the GNOME_VFS_FILE_INFO_GET_ACCESS_RIGHTS flag).  Thanks for your help, Christian.

Reassining to GnomeVFS docs so that it doesn't get lost.

gnome-vfs has been deprecated and superseded by gio/gvfs since GNOME 2.22, hence mass-closing many of the gnome-vfs requests/bug reports. This means that gnome-vfs is NOT actively maintained anymore, however patches are still welcome.

If your reported issue is still valid for gio/gvfs, please feel free to file a bug report against glib/gio or gvfs.

@Bugzilla mail recipients: query for gnome-vfs-mass-close to get rid of these notification emails all together.


General further information: http://en.wikipedia.org/wiki/GVFS 
Reasons behind this decision are listed at http://www.mail-archive.com/gnome-vfs-list@gnome.org/msg00899.html