This seems very much as a duplicate of bug 65058.
But I agree that doing it at the gnome-vfs layer would be much cooler than doing
it directly in nautilus so I'll leave this bug open. Perhaps you should add this
suggestion to that bug too, cause I too think this needs to be fixed and soon.

Excellent, we'd need some way to ensure that root permissions don't remain open,
for example if you opened a file as root user and left it open accidentally,
you'd either need some kind of mechanism built in to remind the user that the
file is open as root, or just ask on every operation, i.e. once to open file,
once to save. Maybe there's something tidier we can do, but leaving root access
open is a lot more dangerous than leaving keyring access to an FTP site open...
if you see what I mean.

I'll make a post on that other bug, I did try a search but couldn't find it.

Cheers

Any implementation ideas?

I am commenting because I also think this feature would be sensible and desirable. 

I would like to be able to move files to areas my account does not have access to on the system, without having to login as root. For example, a person who has a webserver to experiment with on their system (or perhaps even a person who has an sftp/ssh session running graphically), may want to move files they are working on into restricted areas.

Currently, this is accomplished by starting the terminal and logging in as root. I then edit/move/whatever the files using terminal commands. If I really need the GUI, I can start nautilus from the terminal.

It would be nice to avoid all of this by simply requesting my root password, or doing a "run as" style query, where I can select a different user account to "su" to for the duration of the operation.

I saw this bug and thought it was pretty interesting, so I'll throw out a few questions:

Since it's a VFS, does it even make sense that root would give you the ability to do what you want? What about SMB? How would you detect that root would let you do what you wanted? Perhaps the most sensible thing would be

1. Attempt operation
2. If fail, attempt as root()
3. Return success / fail

However, this makes us look dumb if we attempt to sudo root for something that obviously won't help us. Perhaps adding a simple is_local() function to each module would solve this. 

Secondly, how can we intelligently un-sudo? My first inclination would be to say, "sudo on open, unsudo on close". However, that makes a lot of sudo's if you're copying a directory. However, I think this could work if you added two functions:

gnome_vfs_begin_operation_hint() - Indicates the beginning of a user operation, such as a recursive copy that would involve opening and closing lots of files. Basically all this would do is set a flag for the process that would stop close from un-sudo'ing. This way, sudo wouldn't be repeatedly called.

gnome_vfs_end_operation_hint() - Indicates the end of a user operation; if the user is currently sudo'ed and no files are open, they would be un-sudo'ed at 
this point. Otherwise, the standard "unsudo on close" mechanic would apply. 

I think I'd definitely be interested in taking a crack at this, let me know if that would be something people would be willing to commit.

Here's another less important question, are we guaranteed that an X server is running? gnome-vfs has commands that run in a bash shell as well

gnome-vfs has been deprecated and superseded by gio/gvfs since GNOME 2.22, hence mass-closing many of the gnome-vfs requests/bug reports. This means that gnome-vfs is NOT actively maintained anymore, however patches are still welcome.

If your reported issue is still valid for gio/gvfs, please feel free to file a bug report against glib/gio or gvfs.

@Bugzilla mail recipients: query for
      gnome-vfs-mass-close
to get rid of this notification noise all together.


General further information: http://en.wikipedia.org/wiki/GVFS 
Reasons behind this decision are listed at http://www.mail-archive.com/gnome-vfs-list@gnome.org/msg00899.html