Moving off to "future".

Reporters mail is bouncing.

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

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

It's so difficult to implement this feature ?

I don't understand why this feature is still not implemented ?
Maybe nautilus developers don't use nautilus for file management ?

Konqueror and lots of other file managers have this feature from early
days.

Btw, this bug was reported almost 3 years ago !!!
Gnome bugzilla *really* should have voting feature, because now nobody
cares about simple users :(

I don't think sarcasm will help getting the feature implemented.
Please don't use bugzilla as a channel for venting frustration that
just makes it harder to find the real information in here.

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

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

This seems to be aduplicate of Bug 40548.

How can I tell this to the BTS?

This bug isn't duplicate of bug 40548.

This bug is about recursive permissions (chmod -R), not only about
multi-file permissions like bug 40548.

What we need is a BUTTON (not a checkbox) to apply recursively.  The
button needs to apply the current permissions recursively.  Just in case
you're confused on what "option" means.

And yes, this is a much needed feature.  My mom isn't going to get
permissions, but at least my aunt will find the button easier than the
command line (she's smarter than mom).

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

some moments that should be cleaned:

1. Is chmod -R really useful? It should at least act differently on directories
and files - on directories often mode should be +rwx, on user files just +rw. So
the common recursive setting won't be very useful.

2. What will be layout of property page. Should it be button or checkbox? Where
it should be localted.

Probably it would be better to write small application for recursive operations.
It can be associated with x-directory mime type and placed in nautilus context menu.

Some restriction that should be handled by this application.

1. Directories and files should have different permissions.

2. Recursive operations can take long time - for example, when chmod on ftp via
gnome-vfs, so we need some feedback.

3. There probably should be optional ability to doing su - other_user.

4. Any other suggestions are welcome. Also it's intresting, is it possible to
perform another type of file operations with this application.

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

Bug 138063 includes a patch for this.  
  
There is 1 other problem than recursive directory changes:  
- When selecting several files, the group of the files cannot be changed.  
  
As someone posted above, Gnome developers certainly use the shell, as the GUI 
is useless.  
 
So what's up guys ? This problem has been reported 5 years ago, and we are now  
in Gnome 2.10 ??? 

This is a reason why i sometimes have to use the comandline for simple tasks. It
would be cool to have this in Gnome 2.12.

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

OK, we have to tackle this somehow.
I'd like to some usability squad opinions on the UI before putting a possibly
broken UI together.
We currently have a check button table containing:

Owner: x Read x Write x Run
Group: x Read x Write x Run
Other: x Read x Write x Run

Special Attributes: x set user id
                    x set group id
                    x sticky

If the user has selected multiple files with different permissions, the buttons
are currently drawn inconsistently, allowing the user to give all files in the
selection the same permissions.

We now have to integrate means to recursively apply changes if the user has also
selected folders. The issue here is that the objects inside the folder can have
any permissions.

How we can IMHO resolve this:
(1) provide an additional checkbox if folders are selected:
      x Apply changes to folder contents
(2) provide a button
      [Apply to Folder Contents]

(1) would only apply changes, (2) would take the folder permission mask and
apply it to the contents as a whole. While (1) is very flexible (as flexible as
chmod), it has the issue that applying one change could take ages, making it a
hazzle to change multiple mask elements. (2) isn't flexible at all, but the user
can decide when the mask fits his needs and then flush the mask it as a whole.
I really hope that there is a third approach conveying the strengths of (1) and (2).
comment 15 and comment 16 also talk about different masks for files/folders in
the selected folder and about sudo. I fear they are somehow out of scope, except
if we come up with a totally different page for folders.

FWIW: Suggestion 2 in comment 21 seems more feasable, as it's awful hard to
remember and undo all of the permissions of every sub, sub-sub and sub-sub-sub
folder which the user might expect when they un-toggle it. A button with a
possible warning "NO WAY TO UNDO THIS ARE YOU SURE?!1!1!??" seems like an
appropriate course of action.

As for permissions that the user cannot change it's simple; Just ignore it or
ask for a sudo.

It'd be awful nice to see this fixed for 2.14, finally.

Could we summarize the requirements thusly:

1) the ability to set the permissions of a selection of files-this seems to work
ok currently, ie. if I open nautilus and select multiple files and then
right-click, select properties and change the permissions all of the selected
files have their permissions set accordingly. Also it should be possible to
change username and/or group ownership-currently this does not work with a
selection of files. 

2) the ability to set the permissions/ownrership of a selection of folders and
their contents recursively-ie. *a* folder and it's sub-folders/contents
recursively AND a selection of folders and their sub-folders/contents recursively. 

issues:
I. can this be integrated with sudo/su to facilitate dealing with files/folder
belong to different users ? can the same facility used in gnome-system-tools for
user(root) authentification be used here ?

For example, I frequently have mutliple files/folders in my home directory with
root ownership (ie. I download a tarball from epiphany opening it in
file-roller(one action-download/open-with file-roller) and extract it to my home
directory, I then open that folder in a terminal and su to root to
configure/make/make install. 

II. can we distinguish between permissions appropriate for folder and those
appropriate for files (+x) ?

Finally can this be done as a nautilus extension, which if properly coded with a
HIG compliant GUI, would then be included as a standard extension ?


Christian Neumair:

"it has the issue that applying one change could take ages, making it a
hazzle to change multiple mask elements."

As an admin of a an LTSP setup with 300 users I frequently had to reset the
ownership of users files to their respective owners. I used a simple bash
one-liner for this task- 'cd /home; for in *; do chown $i:users -R /home/$i;
done'. This took a max of 2 minutes for 300 users with circa 10 GB worth of
files. I don't think the amount of time involved in changing
ownership/permissions is a critical issue for 99% of expected use of this
functionality. 

"comment 15 and comment 16 also talk about different masks for files/folders in
the selected folder and about sudo. I fear they are somehow out of scope, except
if we come up with a totally different page for folders."

Coming up with a totally different page for folders would effectively kill the 
recursive functionality. It seems like the primary concern regarding the
difference between folder and files is the question about whether or not +x
should be applied to files as well as folders. If this is the case we could
simply have:


(1) provide an additional checkbox if folders are selected:
      x Apply changes to folder contents
      x Apply +x attribute to folders AND files

the second checkbox would be greyed out unless +x was set in the mask, once +x
is set in the mask the second checkbox would be activated(non-greyed out). In
the default ie. without selecting the second checkbox, all changes to the mask
would be applied recusrviely to all files and folders excepting +x for files. 

I sincerely hope it is possible to implement a sudo/su facility for changing
owner of files and/or folders-this would be a tremendous improvement in
usability. I know that gnomesu was not included in the platform and that there
has been an ongoing debate about how to best include such functionality. This is
why I mentioned the possibility of using the same functionality present in
gnome-system-tools for the explicit purpose of implementing superuser
functionality in changing owner/permission. 

Karl: Thanks for your extensive feedbacks. In bugzilla, long comments are rather
bad, though. They make it very hard to follow the thread.
Some comments:

> it should be possible to change username and/or group ownership-currently
> this does not work with a selection of files.

This is a different bug I haven't stumbled across. Maybe you could file this as
a new report?

> can (the recursive permission changing) be integrated with sudo/su

This is nontrivial. We IMHO have to provide means for dealing witht that at the
VFS layer. It is a totally new can of worms.

> I frequently have mutliple (extracted tarballs) in my home directory with
> root ownership (because I) su to root to configure/make/make install.

I'd suggest that you use configure, make and sudo make install. This isn't
really a valid use-case.

> I don't think the amount of time involved in changing
> ownership/permissions is a critical issue for 99% of expected use of this
> functionality.

However, we have to consider NFS mounts as well.

> It seems like the primary concern regarding the
difference between folder and files is the question about
> whether or not +x
should be applied to files as well as folders.

Good point.

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

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

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

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

Updating version information, milestoning to 2.14.

A patch for this functionality was submitted, it will most likely be available under the URI

http://mail.gnome.org/archives/nautilus-list/2005-December/msg00089.html

as soon as the mail server processed it.

Created attachment 56394 [details] [review]
Proposed Patch

Created attachment 56398 [details] [review]
Slightly cleaned-up patch

My first email still doesn't seem to have arrived at the Nautilus mailing list, maybe mailman is broken. Nevertheless, this patch is slightly cleaned up and should be more readable.

IMHO It's just needed a checkbox "Recursive".
If this checkbox is setted then the permissions are applied to all the files, folders, and all files and folders contained in the selected folders...Simple ;)

Sorry for the recursion :)

With GNOME's instant-apply a tickbox is absolutely wrong. Aside from anything else it's dangerous - you could be flicking over half a dozen bits on every file below the current directory and you're not even getting confirmation?

A button at the bottom labelled "apply to all files and folders within this one" would be better. Recursive permissions are sufficiently dangerous that a longer label than "apply recursively" is warranted and a button makes it clearer that this is an action with important consequences than a tickbox as the change certainly can't be reversed just by unticking the box.

 - Chris

Created attachment 56491 [details] [review]
Proposed prelimitary patch #2

Not yet cleaned up, but vastly improved.

http://blogs.gnome.org/view/cneumair/2005/12/26/0 contains some informoation on the first approach
http://blogs.gnome.org/view/cneumair/2005/12/28/0 has info on the second patch

Both entries contain very helpful comments, please read a few of them before making suggestions.

> please read a few of them before making suggestions.

Please don't get me wrong, I'm actually encouraging you to give comments :).

Gnome 2.14 beta1 has now been released and we are now entering the UI freeze period.

But nautilus recursive directories permissions still don't exist (I'm now using nautilus 2.13.90, and if you use Gnome you still need to edit 1000's of files manually if you don't have a sysadmin at hand who knows the shell).

We've now been waiting 6 years for this. So what's up ? Any news ? Or will this be postponed to Gnome 99.99 ?

As a user and as a Linux/GNU/Gnome enthusiast, I totally share JW frustration with Nautilus on this issue; other than that, it is really a great tool. Hopefully this proposed preliminary patch mentioned below will make it to production soon.

Thanks developers!
Ariel

I'm currently using Ubuntu 5.10 and this has been one of my biggest frustrations.  Ubuntu 6.04 (Dapper Drake) is going to be rolling out in April with Gnome 2.14, it would be a shame for this feature to be pushed back another 6 months.  I agree that it could just be a mini app.  ...but gripes aside, I really appreciate all of the work that is being done on Gnome!

Thanks again,
Laren

Created attachment 60752 [details] [review]
Proposed patch #3

Third approach. The motivation for this layout is explained under
http://blogs.gnome.org/view/cneumair/2006/03/06/0

Just a remark on the widget labels on the above approach (comment #40).

In the "Access Rights" tab, you have the following labels:

  Owner:  chris
  Access: Read and Write

  Group:  chris
  Access: Read

  Others: None

For somebody uninitiated to Unix perms, this could be confusing, as it is not clear that (a) each "Access" label is different, and is a property associated with the above label (Owner or Group), and (b) that "Others" is also an "Access" label that performs the same function for a different set of users.

I would propose one of the following, to more strongly and consistently associate the Access selection with the specific set of users:

  Owner:         chris
  Owner access:  Read and Write

  Group:         chris
  Group access:  Read

  Others access: None

or:

  Owner:  chris   Access: Read and Write

  Group:  chris   Access: Read

  Others:         Access: None

or:

  <b>Owner</b>
       User:    chris
       Access:  Read and Write

  <b>Group</b>
       User:    chris
       Access:  Read

  <b>Others</b>
       Access:  None

Sorry, that should be the following for the third example, replacing "User" by "Group name" under "Group":

  <b>Owner</b>
       User name:  chris
       Access:     Read and Write

  <b>Group</b>
       Group name: chris
       Access:     Read

  <b>Others</b>
       Access:     None

Luke: I was aware of that quirk when designing the dialog. However, I'm not aware of any layout which doesn't cause visual noise. A grid layout always forces you to scan it in two dimensions to grasp each widget's purpose, and your first proposal will cause 0.5 times more labels to be present on the properties page, which IMHO isn't viable.

What about dropping some of the labels, giving

  [chris] may [Read and Write]
  [chris] may [Read]
  Others  may [Not have access]

Raises a few translation issues by putting things in English word order, but it is very compact.

How do you resemble that the first [chris] entry refers to the owner, and the second [chris] entry to the group without adding more labels? Even if we provide means of modifying the grid layout for other languages, how do we ensure painless keynav?

Would the window have to be significantly wider or taller to support the second or third suggestion in Comment #41?  Is it taboo to make the window any bigger?  (I'm guessing the answer is yes...)

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

Created attachment 63420 [details] [review]
Updated the patch for Nautilus 2.14.1

Would a better solution here be to drop the instant apply thing for permissions? I read through the thread but I did not really see any suggestion of this.

This would make the problem a lot simpler; the dialog could be laid out like this:

File owner: sam - Sam Douglas
File Group: [sam ^]
--------------------------------

Owner:    Read   Write   Exec
Group:    Read   Write   Exec
Others:   Read   Write   Exec

--------------------------------

Special flags:   Setuid
                 Setgid
                 Sticky

             [ Apply Permissions ]
--------------------------------
 ...

While this is not exactly "normal" in Gnome, it makes far more sense, and is
a lot safer than having permissions applied instantly.

Now for solving the recursion problem; you could either offer an "Apply recursively" checkbox or you could take an approach similar to what Microsoft did in Windows 2000, and display another dialog box if it is possible the permission change could apply to a tree of files (i.e. if a directory is selected) where you give the option to:
    () Apply to this directory only; do not change its contents
    () Apply to this directory and all subdirectories and files
    () Apply to this directory and all subdirectories and files ****

**** Umm, I couldn't think of a concise term for this off the top of my head, but this option would only apply the execute permission to items that already have execute permissions - i.e. the same as chmod +X does.

This appoach also helps when dealing with files over NFS or SFTP or something, especially when you have a slow connection.

- Sam Douglas

Sorry Christian; just read your blog posting ("All your permissions are belong to us"). I still stick with the [ Apply Permissions ] button idea; one thing I really hate about the existing method is the way it does it as you go; not very fun for working over SSH on a dialup modem or anything.

Hope to see it fixed in the next version; until then I hope I do not put a directory tree into the trash that does not have write permissions.

Thanks
Sam Douglas

"Major changes in 2.15.4 are:
* New permission dialog with recursion and selinx support
..."

marking as fixed