(In reply to comment #0)
> Hello
> 
> From original report:
> https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/822993
> 
> To reproduce, gksudo nautilus to get root permissions, find a folder with files
> inside. Right click the folder and choose properties, go onto the permissions
> tab and change the owner and group to something else, eg to ubuntu if root, or
> root if ubuntu. Click the 'Apply perms to enclosed files' option and then close
> the window. Wait a bit before closing it if you wish, but when you go into that
> folder and check the permissions of the files inside, they will not have
> changed.

I'm an Ubuntu contributor, and I have verified that this occurs not only when you are root but also when you are a normal user changing permissions in your home directory.  I have been trying to fix the bug in my spare time, but I'm still learning the ropes of GTK+ (I do know programming, but have only recently started fixing bugs for Ubuntu).  

I would appreciate any help either here or on Launchpad.  Thanks!

I haven't been able to figure this out yet after a week of trying to figure out nautilus's internals.  Basically, here is how far I've gotten:

1) In src/nautilus-properties-window.c, there exists a function apply_recursive_clicked() that is linked to the "Apply permissions to enclosed files button".

2) There is a for loop near the end of apply_recursive_clicked() that takes the values from the permissions combo boxes and applies them recursively to the contents. Within this loop, the permissions are applied using nautilus_file_set_permissions_recursive(), which is located in libnautilus-private/nautilus-file-operations.c.

3) In nautilus_file_set_permissions_recursive(), a SetPermissionsJob object takes on the permissions values passed to it, but not the owner and group. I added char values for those to the function, but then had to go back to the SetPermissionsJob class definition and add group and owner as parameters (which may not be the optimal way to do this...).

4) What's even more confusing now in nautilus_file_set_permissions_recursive() is the following, after the SetPermissionsJob object receives its values:

if (!nautilus_file_undo_manager_pop_flag ()) {
  job->common.undo_info =
   nautilus_file_undo_info_rec_permissions_new (job->file,
             file_permissions, file_mask,
             dir_permissions, dir_mask);
               }

 g_io_scheduler_push_job (set_permissions_job,
      job,
      NULL,
      0,
      NULL);

I found a nautilus_file_undo_info_rec_permissions_new() in nautilus-file-undo-operations.c, as well as nautilus_file_undo_info_ownership_new(). However, I'm not sure how I would implement nautilus_file_undo_info_ownership_new() since its name suggests that it isn't recursive. I'm not sure where to progress from this point, but I have definitely gotten a lot clearer on how this all could be tied together.

(In reply to comment #2)
> I haven't been able to figure this out yet after a week of trying to figure out
> nautilus's internals.  Basically, here is how far I've gotten:

Hi Ken, sorry for the slow response; the UI Nautilus has for this feature is actually really confusing, since the "Apply permissions to enclosed files" button is only meant to apply *permissions* (as in the values of the "Folder/File Access" comboboxes) recursively, and not group and owner information (and it works in that regard).

The code path you're describing below in fact applies the currently specified values of those comboboxes recursively to the contents of the folder, using nautilus_file_set_permissions_recursive(). More on this below.

> 4) What's even more confusing now in nautilus_file_set_permissions_recursive()
> is the following, after the SetPermissionsJob object receives its values:
> 
> if (!nautilus_file_undo_manager_pop_flag ()) {
>   job->common.undo_info =
>    nautilus_file_undo_info_rec_permissions_new (job->file,
>              file_permissions, file_mask,
>              dir_permissions, dir_mask);
>                }
> 
>  g_io_scheduler_push_job (set_permissions_job,
>       job,
>       NULL,
>       0,
>       NULL);
> 
> I found a nautilus_file_undo_info_rec_permissions_new() in
> nautilus-file-undo-operations.c, as well as
> nautilus_file_undo_info_ownership_new().

What this code does is setting up information for undoing the operation later, and does not modify the actual operation being performed in any way...

If you wanted to fix this, you would need to write additional recursive methods to set group/owner, extending nautilus_file_set_group()/nautilus_file_set_owner() in the same way nautilus_file_set_permissions_recursive() does it compared to nautilus_file_set_permissions(), and wire it up to the properties dialog.

As I said I am not really a fan of the UI that we expose for this though, but I guess the backend code could then be re-used if we decide to switch to a different UI.

The UI in master makes it more clear that the owner and group is not applied to the enclosed files.