Restore from trash appears to do a file copy

[Caleb]

When I restore a file from the trash by dragging it back to some other folder on my system, GVFS appears to copy it and then delete it, as if it were on another filesystem, rather than just moving it. This takes a long time, promotes fragmentation, and uses disk space. It should just change the file's path, like moving any other file on the system.

[Pedro Villavicencio (pedro)]

more like a gvfs issue , re assigning.

[Caleb (caleb-marcus)]

That's what I originally assigned it to :)

[Ashley Kyd (ashkyd)]

I'm having this problem, except the file I'm trying to move out of the trash produces the error that there's not enough free space. It's on the same filesystem, so essentially I can't get it out of trash without "copying" it to another server with free space, and back again.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gvfs - 0.99.6-0ubuntu1

---------------
gvfs (0.99.6-0ubuntu1) intrepid; urgency=low

  * New upstream version:
   - Better cross-backend copy/move logic. Now will perform an actual file
     system move if possible, even when the source and target are handled
     by different backends
    - Now requires libsoup >= 2.23.91.
    - Bug fixes
    548841 - Incorrect usage of plural forms in gphoto backend
    547133 - Getting mtime over http backend is broken (lp: #247980)
    538573 - lastmodified uses ISO 8601 date/time where it should use http-date
    549253 - error path leaks
    549553 - gvfs mangles uri for unhandled schemes
    550100 - gio uses 10^3 base (SI) for volume names
    529971 - Restore from trash appears to do a file copy (lp: #222150)
    RH 460223 - gnome-mount no longer automatically opens LUKS-encrypted
    partitions

 -- Sebastien Bacher <email address hidden> Tue, 02 Sep 2008 11:49:45 +0200