Still here with nautilus 2.4 => GNOMEVER2.4

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

This is a major problem, upgrading Priority -> High, and Severity -> Major.

At the time of emptying trash  check whether the user has the write permission 
for the trash content .If not we just changing the mode using chmod .This will 
give the expected behaviour..
  
       Whether the approch used is correct ?

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

Created attachment 38355 [details] [review]
This will rectify probelm 

I am attaching a patch.Hope this approch is correct ..Please review the patch
and give a valuable sugg
Anoop

the patch is on gnomevfs, reassigning

Anoop: Thanks for your efforts! Unfortunately, this patch is not acceptable for
a couple of reasons:
a) you break abstraction. You should use GnomeVFS file info methods instead of
using access and friends, which only works for local files
b) your patch breaks atomocity. If we fail to empty or finally fail to remove
the directory, you should revert the permission change.
c) from taking a short look at the file, there could be a couple more places in
the source code where similar changes will be neccessary

Sorry for the late response, btw.

Hi!

I think this issue is not related to gnome-vfs but to trash behaviour. When I
try to delete a directory like the one in the example using "rm -r", the system
tries to delete files and directories I have permission to, so I expect the same
behaviuor from gnome-vfs.

If empty trash function should work in a different way then that should be
implemented outside gnome-vfs as it is specific to the trash functionality.

It works fine with the current GNOME for me, does anybody still have this issue?

I'm using current gnome ( 2.12.3 ), and I'm seeing exactly the behaviour as reported.

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

still happens with 2.14, re-setting version

This bug is now 3 years old!

Might I suggest that the proper behavior is to warn the user when they delete the directory.  gnome-vfs should check the directory tree and inform the user that part of it is read-only and ask them if they want to move it to the trash anyway.  Then when you go to empty the trash it doesn't have to deal with the problem.  

an error message would be nice

Still occurs with gnome-vfs 2.18.1 on Ubuntu Feisty.

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

Using gnome 2.19.92 on Ubuntu Gutsy, I am not able to recreate this bug. Has it been fixed?

It's hard to know if this bug has been fixed because nobody has described the symptoms of the problem? What do you see that you should not see?

I do notice that the test folder created according to the instructions is not deleted from the trash when I use "Empty Trash", and I see no error dialog about that. I don't know if that's the original problem.

Murray, you're not serious, right ?

I gave an explicit testcase and it is still valid.

If a directory containing a subdirectory which is not writable by user get moved into Trash, you won't be able to empty trash.

OK. Originally I followed the instructions wrong. However, when following the instructions correctly under 2.19.92, I am given a series of error messages, instead of no error messages like the bug describes.

Is this the correct action though? Because the user still owns the directory, shouldn't he be able to delete it? Example:

cd
touch file
chmod 000 file
rm file

I am able to delete the file. Another example:

cd
mkdir test
chmod 000 test
rmdir test

Again no errors because I own the folder.

as an addition to original bug report, it was always complaining with popups since the beginning ;)

I suppose gnome-vfs and nautilus are treating the files correctly since the same occurs from the terminal:

cd
mkdir -p test/test
touch test/test/file
cd test
chmod -R a-w test
cd
rm -r test

"rm: cannot remove `test/test/file': Permission denied"

I think this bug should probably be marked as fixed since and filed somewhere else like coreutils.

in that case, nautilus shouldn't accept to move these files to trash

> I gave an explicit testcase and it is still valid.

Frederic, you said "try emptying trash". That doesn't describe what you experience. That suggests that we try what you tried so we can experience the same thing. How can we know when we've experienced the same thing? You're not making it easy for anybody to know what the problem is or when it is fixed, regardless of whether there may be several other related problems being discussed here.

Is it desirable though to have gnome-vfs recursively checking permissions on folders before it moves them to the trash? If it is desirable, would the overhead be acceptable? Especially on large folder hierarchies, it seems like it would be unnecessarily intensive.

Either way, this bug should probably marked as fixed as nautilus is acting correctly when it can't delete files. If something more is going to be done with gnome-vfs or nautilus when moving files into the trash a separate bug should probably be filed.

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

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

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

I believe this bug should be marked as invalid. To double check, I asked the coreutils mailing list, and the following is expected and desired behavior.

cd
mkdir -p test/test
touch test/test/file
cd test
chmod -R a-w test
cd
rm -r test

"rm: cannot remove `test/test/file': Permission denied"

Gnome-VFS is behaving correctly by giving an error message when trying to empty the trash with test/test/file in it.

I suggest closing this bug. I also believe that Bug 476338 should be looked into since this "bug" is still being reported/duplicated.

> Gnome-VFS is behaving correctly by giving an error message when trying to empty
> the trash with test/test/file in it.
> 
> I suggest closing this bug. I also believe that Bug 476338 should be looked
> into since this "bug" is still being reported/duplicated.
> 

Joseph,

you're right in saying that gnome-vfs is behaving correctly. But you're missing the point here. The real question is not whether gnome-vfs is behaving correctly but whether the "empty trash" feature is behaving correctly (removing all files from the trash). When a user chooses to empty the trash, nautilus should do its best to satisfy the user, and empty the trash. If it doesn't, it's a bug. In this case Nautilus should try to set all the files and folder writeable before trying to remove them. Then, gnome-vfs would be able to behave correctly by deleting the now writeable files and folders.

I can reproduce this bug...

So all that needs to be fixed is: to tell the Trash only to accept permissions that the user can later delete. If not, change the permissions. If it can't change the permissions under the current user, display and error and don't delete.

No,

I agree with Julien. Any user should be allowed to move non-writable folders to the trash. The "empty trash" functionality, if it comes across read-only contents, should ask the user whether it should leave the folders/files or attempt to fix the permissions for it to remove the contents.

Nautilus should not interrupt the moving of contents to the trash. This would add a substantial amount of unnecessary overhead.

If you expect 'move to trash' to behave the same as 'rm' from the command line, then you should not move read-only objects to the trash folder.

If that is done then 'empty trash' will always be able to complete, since only files which are writable by the user will be in the wastebasket.

This seems logical and consistent.

If you expect different functionality, then any references to what 'rm' does or does not do are not relevant.

Closing this bug as obsolete, as we now have a fix in for bug 404600 in GVFS (which is more or less the same bug).