Re: [PATCH] [RFC] Recursive file permissions

Am Samstag, den 04.03.2006, 17:07 +0100 schrieb Christian Neumair:
> Am Donnerstag, den 12.01.2006, 11:12 +0100 schrieb Alexander Larsson:
> > On Mon, 2005-12-26 at 01:26 +0100, Christian Neumair wrote:
> > > The attached patch is meant to implement recursive file permission
> > > changes [1]. I'm eagerly awaiting feedback, in particular whether the
> > > GUI offers enough usability for you.
> > > 
> > > [1]
> > 
> > I must say I much prefer your later blog posting. I still don't think
> > its ideal though. Also, i very much like this:
> >
> > 
> > One thing I think that can help a lot, both in the normal UI and in the
> > recursive apply mode is to separate out executable into two widgets, one
> > that handles "executability of files" and one that handles "listability
> > of folders" (the last one won't be visible if you only select files of
> > course). That way you don't have to know what executable bit means for
> > folders, and you could set different execute bit for folders and files
> > in the recursive case.
> I agree that the Thunar guys did a very good job at the permissions GUI.
> > Also, i don't think instant apply recursive apply of permissions is
> > right. Its gonna be very slow to apply each change you make (you might
> > want to make multiple changes), and you can easily loose a lot of data
> > (permission settings) if you accidentally do something wrong.
> I disagree that Instant-Apply is wrong here. In Thunar, you're asked
> after each change whether to apply it recursively or not. I think we
> have two user groups: Those who know precisely what they're doing, and
> those who have a basic glimpse about what granting permissions means in
> practice but don't know about UNIX permissions. We should offer
> something to both, with the basic dialog being identical to Thunar's.
> I'll explain the advanced mode down below.
> > My current opinion is that we should take the thunar dialog, with is
> > pretty similar to yours, but with the execute bit moved out of the
> > access dropdowns. It also has IMHO better layout and nice icons. 
> > To this we add:
> > 1) Checkboxes under group and other access that says "Allow these users
> > to list files in folders" (or something like that). (We assume that
> > users always wants the execute bit set for themselves on folder, but if
> > a selected file has this off we can add it in so that the user can fix
> > it).
> > 2) Add an "Apply to files in enclosed folders" (want better string?)
> > button that applies the permission settings to files and folders inside
> > selected folders.
> > 3) Add a "details" button
> > 
> > Some notes:
> > 
> > We don't want "None" in the list of alternatives for the user
> > permissions. There is no need to make your own files non-readable to
> > you. Nor is there any need to make your own folders non-listable to you.
> > 
> > The execute checkbox toggles all execute perms. I don't think there is a
> > need for more detailed exectute rights in the standard perms view.
> I agree.
> > The advanced dialog looks a bit like yours, but without the subfolder
> > settings. Instead it has two columns for the execute bit "execute file"
> > and "list folder contents", and there is a recursive apply button. 
> > 
> > Also, maybe we should have the advanced widget ("details") appear in the
> > same place as normal widget instead of its own dialog. Dialogs from
> > dialogs is a bit weird, and i think it makes sense to "switch to
> > advanced mode" even if looks a bit like tab-in-tab.
> I'd prefer a chmod GUI which allows you to enter something like +rwX and
> displays the octal permissions, umask etc. I don't see any target
> audience for an advanced mode similar to that one proposed in my blog,
> but maybe I just don't know our user base well enough. Maybe you could
> explain under which circumstances it would be useful?

For an implementation and short discussion of that approach, please
refer to [1], additional comments are probably scattered on


Christian Neumair <chris gnome-de org>

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]