File access field is not properly updated in folder properties (Nautilus)

Bug #503315 reported by florin on 2010-01-05
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Nautilus
New
Medium
One Hundred Papercuts
Undecided
Unassigned
nautilus (Ubuntu)
Low
Ubuntu Desktop Bugs

Bug Description

Distribution: Ubuntu 9.10 Karmic Koala

Input: Start Nautilus and right click a folder; select "Properties" -> "Permissions" tab and change "File access" for a group of users (e.g. setting read only access for "Others"). Click on "Apply permissions to enclosed files"

Expected: permissions up-to-date and "file access" control in dialog updated with the new status

Deviation: permissions are set but the control in not properly updated (e.g. showing "read-only" for others). It still shows "---"

Papercut: user is not able to tell from "Properties" form whether the system has indeed changed the permissions; it is also not possible to view later which permissions were assigned to files in that folder and subfolders

Open point: what about the situation when mixed permissions are available in the folder? For example I have a top folder with 5 subfolders, 3 of them with files "read-only" for "Others" and the rest with no access of any kind for "Others". The "file access" control should show that I have mixed permissions (it still shows "---")

Changed in nautilus (Ubuntu):
importance: Undecided → Low
Bruno Girin (brunogirin) wrote :

@florin: can you be more specific in your description please? I'm trying to reproduce this bug but when I change the permissions on the folder, it is immediately reflected in the Nautilus window. However, clicking on "Apply permissions to enclosed files" doesn't seem to do anything. Any idea what it should do?

What I've done so far is:
Created a directory called dir1
Created a two files in dir1 called file1.txt and file2.txt
Created a sub-directory in dir1 called subdir1
Created a file in subdire1 called file1.txt

I can change permissions on dir1 or subdir1 and it is reflected immediately. Clicking on "Apply permissions to enclosed files" does nothing.

How does that differ from what you observe and what do you expect "Apply permissions to enclosed files" to do?

Changed in nautilus (Ubuntu):
status: New → Incomplete
Download full text (3.4 KiB)

Hello Bruno,

This is what I do: in my Videos folder I have some subdirectories with some
movies I would like others to see as well; I select "Videos" and right click
it to get the properties dialog, permissions tab; I can see that folder
permissions is set to "access files", and they can do that, but the point is
that they can't open a file which is not a folder (an avi, for example). I
have to use "apply permission to enclosed files" to set correct "read"
permissions on the files (control "file access" for "Others") within the
subfolders, which is fine, but the control does not show what I just did (it
remains "---" instead of "read-only" for example).

Permissions are set, updating the control value to match that does not
happen. Clicking "apply permissions to enclosed files" sets them, but no
visual feed-back lets you know what just happened, but a small update of the
last changed field, beneath SELinux context
I hope this helps,

Florin

On Wed, Jan 6, 2010 at 9:37 PM, Bruno Girin <email address hidden> wrote:

> @florin: can you be more specific in your description please? I'm trying
> to reproduce this bug but when I change the permissions on the folder,
> it is immediately reflected in the Nautilus window. However, clicking on
> "Apply permissions to enclosed files" doesn't seem to do anything. Any
> idea what it should do?
>
> What I've done so far is:
> Created a directory called dir1
> Created a two files in dir1 called file1.txt and file2.txt
> Created a sub-directory in dir1 called subdir1
> Created a file in subdire1 called file1.txt
>
> I can change permissions on dir1 or subdir1 and it is reflected
> immediately. Clicking on "Apply permissions to enclosed files" does
> nothing.
>
> How does that differ from what you observe and what do you expect "Apply
> permissions to enclosed files" to do?
>
>
> ** Changed in: nautilus (Ubuntu)
> Status: New => Incomplete
>
> --
> File access field is not properly updated in folder properties (Nautilus)
> https://bugs.launchpad.net/bugs/503315
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in One Hundred Paper Cuts: New
> Status in “nautilus” package in Ubuntu: Incomplete
>
> Bug description:
> Distribution: Ubuntu 9.10 Karmic Koala
>
> Input: Start Nautilus and right click a folder; select "Properties" ->
> "Permissions" tab and change "File access" for a group of users (e.g.
> setting read only access for "Others"). Click on "Apply permissions to
> enclosed files"
>
> Expected: permissions up-to-date and "file access" control in dialog
> updated with the new status
>
> Deviation: permissions are set but the control in not properly updated
> (e.g. showing "read-only" for others). It still shows "---"
>
> Papercut: user is not able to tell from "Properties" form whether the
> system has indeed changed the permissions; it is also not possible to view
> later which permissions were assigned to files in that folder and subfolders
>
> Open point: what about the situation when mixed permissions are available
> in the folder? For example I have a top folder with 5 subfolders, 3 of them
> with files "read-only" for "Others" and the rest with...

Read more...

Bruno Girin (brunogirin) wrote :

OK, I think I understand what it does now. However, I'm not sure what the correct behaviour should be. Changing the "file access" drop down box to "read-only" only makes sense until you add new files to this folder. On the other hand, some sort of feedback would be nice. What do you think should be the correct behaviour?

florin (florin-valcu) wrote :

Hi,

I would say to follow the specifications, if they are available :)
If not, I think it would be nice to see the access rights. For the situation
you have described, when they are mixed, it should say something like
"(mixed access rights)" (which should be unselectable). I will think about
it when I have the time and I will send you another ideea, as well

On Mon, Jan 11, 2010 at 3:25 AM, Bruno Girin <email address hidden> wrote:

> OK, I think I understand what it does now. However, I'm not sure what
> the correct behaviour should be. Changing the "file access" drop down
> box to "read-only" only makes sense until you add new files to this
> folder. On the other hand, some sort of feedback would be nice. What do
> you think should be the correct behaviour?
>
> --
> File access field is not properly updated in folder properties (Nautilus)
> https://bugs.launchpad.net/bugs/503315
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in One Hundred Paper Cuts: New
> Status in “nautilus” package in Ubuntu: Incomplete
>
> Bug description:
> Distribution: Ubuntu 9.10 Karmic Koala
>
> Input: Start Nautilus and right click a folder; select "Properties" ->
> "Permissions" tab and change "File access" for a group of users (e.g.
> setting read only access for "Others"). Click on "Apply permissions to
> enclosed files"
>
> Expected: permissions up-to-date and "file access" control in dialog
> updated with the new status
>
> Deviation: permissions are set but the control in not properly updated
> (e.g. showing "read-only" for others). It still shows "---"
>
> Papercut: user is not able to tell from "Properties" form whether the
> system has indeed changed the permissions; it is also not possible to view
> later which permissions were assigned to files in that folder and subfolders
>
> Open point: what about the situation when mixed permissions are available
> in the folder? For example I have a top folder with 5 subfolders, 3 of them
> with files "read-only" for "Others" and the rest with no access of any kind
> for "Others". The "file access" control should show that I have mixed
> permissions (it still shows "---")
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/hundredpapercuts/+bug/503315/+subscribe
>

--
Florin

Omer Akram (om26er) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/GNOME. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

Bruno Girin (brunogirin) wrote :

@om26er: I will forward upstream. I was hoping we could define expected behaviour better but I guess we can leave that to upstream as they will know better what sort of feedback they want their application to provide.

Bruno Girin (brunogirin) on 2010-01-14
Changed in nautilus (Ubuntu):
status: Incomplete → Confirmed

Thanks for sending this upstream.

Changed in nautilus (Ubuntu):
status: Confirmed → Triaged
assignee: nobody → Ubuntu Desktop Bugs (desktop-bugs)
Omer Akram (om26er) wrote :

Thank you for bringing this bug to our attention. However, a paper cut should be a small usability issue , in the default Ubuntu 9.10 install , that affects many people and is quick and easy to fix. So this bug can't be addressed as part of the project.

either this is a bug or its the expected behavior (might be for security reason but not a papercut

For further info about papercuts criteria , pls read > https://wiki.ubuntu.com/PaperCut

Don't worry though, This bug has been marked as "invalid" ONLY in the papercuts project.

Changed in hundredpapercuts:
status: New → Invalid
Changed in nautilus:
importance: Unknown → Medium
status: Unknown → New
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.