[26964] in Athena Bugs
Re: linux 9.4.30: nautilus
daemon@ATHENA.MIT.EDU (Matthew Goldstein)
Mon Sep 18 12:18:25 2006
Date: Mon, 18 Sep 2006 12:18:13 -0400 (EDT)
From: Matthew Goldstein <austein@mit.edu>
To: Robert Basch <rbasch@mit.edu>
In-Reply-To: <200B1EA1-545A-4038-B9EE-83EFC61F61AB@mit.edu>
Message-ID: <Pine.LNX.4.62L.0609181142130.1914@dewey.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 1.217
X-Spam-Level: * (1.217)
X-Spam-Flag: NO
Cc: bugs@mit.edu
Errors-To: bugs-bounces@mit.edu
Hi Bob,
Sorry about that, I should have tested the case of copying instead of
moving. Just copying the file over works fine.
Here is an interesting (though I suppose obvious) byproduct of this
problem. Nautilus by default moves files to the trash rather than delete
them. So, for any student working in a course locker with Nautilus,
attempts to delete files generates an error because Nautilus is trying to
use rename() and move it to Trash in the user's homedir.
As far as I can tell, the only solution using naitulus is a
setting in Edit->Preferences at the bottom of the Behavior tab,
for "Include a Delete command that bypasses Trash".
Doing this creates an option on the right-click (or Edit) menu for Delete.
I realize that there is only a slight chance of this happening, but would
it be possible to have that box checked by default to make it easier for
students to work within lockers?
Thanks
Matthew Goldstein
Athena Consultant
On Tue, 12 Sep 2006, Robert Basch wrote:
> On Sep 12, 2006, at 2:25 PM, Matthew Goldstein wrote:
>
>> Attempting to copy a file from my homedir to the directory which I
>> had AFS write access to returned the error "Not on the same file system"
>> from nautilus. Creating a subdirectory which I owned yielded the same
>> error. Also, copying a file from the other user's Public to my homedir
>> generated the same error again.
>> Copying files from the local machine to both the other user's Public and to
>> my homedir worked.
>
> Were you trying to copy or move the file? I can reproduce the
> error when trying to move a file, but copy works OK.
>
> The move error occurs when the source and target are in
> different AFS volumes. The offending code assumes that
> it should be able to use rename() when the source and
> target are on the same file system, but the check for the
> latter only tests whether they are on the same device, as
> returned by stat(); that will be true for any paths in AFS.
> The rename() fails when the paths are in different volumes,
> though.
>
> There are other cases where this rename() assumption is
> a bad one, and there is actually a GNOME bug filed on this
> (http://bugzilla.gnome.org/show_bug.cgi?id=309592). A
> proposed patch was attached to the bug report a while ago,
> but progress on it seems to have stalled. We will look into
> this further...
>
> Thanks for reporting this.
>
> Bob
>
