[SRU] cut-n-paste move files got stuck forever

Bug #1133477 reported by Teo on 2013-02-26
336
This bug affects 78 people
Affects Status Importance Assigned to Milestone
caja (Ubuntu)
Undecided
Unassigned
Xenial
Undecided
Unassigned
gvfs (Ubuntu)
Undecided
Unassigned
Xenial
Critical
Simon Quigley
nautilus (Ubuntu)
Undecided
Unassigned
Xenial
Undecided
Unassigned
pcmanfm (Ubuntu)
Undecided
Unassigned
Xenial
Undecided
Unassigned

Bug Description

[Impact]
Without these fixes, copying any more than a few files in several file managers including but not limited to Nautilus and Caja either completely freezes up the file manager (if this happens with a Cut and Paste, it destroys user data by leaving files half moved) or slows it down to a crawl. These bugs are not found when using the mv command in the terminal, which will copy the files in a couple of seconds at maximum. This is a nightmare for people who want to Cut and Paste a lot of files and who need to do it quickly.

[Test Case]
Either find some files that you would be OK losing (or have a backup for) or create the files yourself. You can run the following command to generate 1024 empty 1 MB files (do this in an empty directory, where you have at least 1 GB of free space), which is a valid way to reproduce this bug:

i=1 && while [ $i -lt 1025 ]; do dd if=/dev/zero of=$i bs=4k iflag=fullblock,count_bytes count=1M; i=$[$i+1]; done

(Credit to https://stackoverflow.com/a/11779492/4123313 and http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_09_02.html - also, neither truncate or fallocate are used because the bug cannot be reproduced when using those tools, my theory is that with dd it actually writes the zeroes, with those tools, they say they wrote the zeroes to the filesystems but it seems they actually didn't (something along the lines of that), although I could be wrong)

If you open Nautilus or Caja, and Cut and Paste these 1024 files somewhere else, the transfer will slow to a crawl, and in one instance where I tried this with 1024 empty 512 MB files, Nautilus actually crashed. This is very different to using mv in the terminal before doing it in the file manager, which transfers these files flawlessly.

Once this fix is applied and I recreate these files, the transfer in Nautilus and Caja is almost as fast as using mv (I'd say within a second), which is what should happen.

[Breakdown of the patches and the regression potential for each]
First, I'd like to thank levien for providing the patch links to fix this. Without that, it would have been a bit more work to hunt down which patches are applicable.

lp1133477-metadata-use-sequences-instead-of-lists.patch:
Patch Description: The metabuilder stores files and data in sorted lists. An insertion into a sorted list is done in linear time, which highly affects efficiency. In order to fix this, use GSequence instead which does insertion and deletion in logarithmic time.

This patch is in here because it helps with a large amount of files. Regardless if the files are 1 MB or 10 GB, the sorting of the files to be moved/copied is inefficient. This addresses part of the problem by making sure large amount of files can be dealt with efficiently. The regression potential for this is low, and the only case that I can see where a package would regress is a file manager that depends on (not 100% on this theory but it's a possibility) monitoring the status of the list at a given time, and is incompatible with using GSequence. In this case, the package would have something peculiar hardcoded, and would most likely have an upstream fix that could be backported because this fix is in the gvfs release that is already in 17.04 and later (so they should have fixed it already). I can't think of a package that does this (from what I can tell, it's not sane code if it isn't compatible with this change) but if something does regress, it should be trivial to fix.

lp1133477-metadata-use-queues-instead-of-lists.patch:
Patch Description: Some of the lists used by the metabuilder have items appended to them. Appending to a list is done in linear time and this highly affects efficiency. In order to fix this, use GQueue which supports appending in constant time.

This patch is extremely similar in function to the last one, but this one addresses items appended to a list instead of files and data in sorted lists. As such, the regression potential is similar (low) because it would involve a package hardcoding some things that are incompatible with GQueue, and would most likely have an upstream fix that could be backported because this fix is in the gvfs release that is already in 17.04 and later (so they should have fixed it already). I can't think of a package that does this (from what I can tell, it's not sane code if it isn't compatible with this change) but if something does regress, it should be trivial to fix.

lp1133477-metadata-fix-bogus-condition.patch:
Patch Description: The file->children condition is always true at this point, child->children should be there instead in order to speed up processing. This fix doesn't affect the functionality, it just slightly improves processing.

This is a trivial iteration on top of the other two patches that improves performance while not affecting functionality. It just seems to eliminate an unnecessary step when executing the file by putting child->children there instead as it improves processing time. The regression potential is low because all of the variables already exist and the patch would have been likely been integrated in one of the other two if they had noticed the performance enhancement. Also, it doesn't affect functionality, so a regression seems unlikely because if one exists it would be in one of the other patches.

lp1133477-client-use-sync-methods-instead-of-flushing-dbus.patch:
Patch Description: g_dbus_connection_flush_sync causes troubles in certain cases when using multiple threads. The problem occurs when there are ongoing gvfs_metadata_call_set_sync calls. It blocks threads e.g. when moving files over Nautilus. Nautilus freezes sometimes due to it. Use sync methods instead of flushing dbus. I don't see any significant slowdown when using sync methods instead of the flushing according to my testing. It fixes hangs in Nautilus and moving in Nautilus is almost instant again.

This patch fixes the Nautilus crashes.

It helps fix the problems introduced in some cases when using mutliple threads are being used. One comment that is removed alongside the code it is noting (this stood out to me) is the following:

/* flush the call with the expense of sending all queued messages on the connection */

It shows that when initially writing this, care wasn't taken to ensure that it would be useful when there is a large amount of queued calls, i.e. in the case of this bug. If the user does not have enough memory (which is my theory about what the issue was when I reproduced this on my hardware, it showed an error message something along the lines of "Out of Memory"), Nautilus will stop and fail to continue the operation.

This takes care to make sure this is never the case, and uses gvfs_metadata_call_remove_sync instead of flushing dbus, which is much more efficient, and helps make sure that given a large amount of files, it will not crash.

In any case, these patches are tracked in upstream bug 757747 ( https://bugzilla.gnome.org/show_bug.cgi?id=757747 ), and if regressions in this code are found, it will likely be noted there.

[Original Description]
With Nautilus, I navigated to a folder that contained about 2,000 gif files.
I selected all of them
I cut with Ctrl+X
I navigated to another folder
I pasted with Ctrl+V

=> A popup window appeared saying "Preparing to move N files", and it got stuck there forever.
Nautilus stopped responding. I waited half an hour, then I had to kill it.

Actually some of the files were moved. Which is the worst thing that could happen.

I tried again with the remaining files and it happened again!! It's systematic!!!!!!

I suspect it has to do with displaying the previews of a big number of files. Nautilus becomes completely unmanageable whenever you open folders with lots of files. Maximum priority should be given to the UI and actual operations; displaying of the previews should be done in the background and should never, ever slow down user operations the slightest bit. Seems pretty obvious.

Also note that 2000 is not even that much. Actually it's very few files.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: nautilus 1:3.5.90.really.3.4.2-0ubuntu4.2
ProcVersionSignature: Ubuntu 3.5.0-25.38-generic 3.5.7.4
Uname: Linux 3.5.0-25-generic i686
NonfreeKernelModules: nvidia
ApportVersion: 2.6.1-0ubuntu10
Architecture: i386
Date: Tue Feb 26 18:23:52 2013
GsettingsChanges:
 b'org.gnome.nautilus.window-state' b'geometry' b"'1312x713+64+71'"
 b'org.gnome.nautilus.window-state' b'sidebar-width' b'180'
 b'org.gnome.nautilus.window-state' b'start-with-status-bar' b'true'
InstallationDate: Installed on 2010-06-23 (979 days ago)
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100429)
MarkForUpload: True
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: nautilus
UpgradeStatus: Upgraded to quantal on 2013-01-13 (44 days ago)

Teo (teo1978) wrote :
Teo (teo1978) wrote :

Note that moving the same amount of files with a "mv" command from a terminal takes a fraction of a second. The exact same should happen with nautilus.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in nautilus (Ubuntu):
status: New → Confirmed
Jay Mac (jmac939) wrote :

I have the same problem. And it happens quit frequently.

Sometimes it will happen when moving with as few as 100 files. But generally it is with folders with higher file counts.

I have seen it happen on my SSD and also via SMB when moving files around on my NAS.

Kurt Huwig (k-huwig-f) wrote :

I have the same issue when copying several dozens of GB from an FTP server via 100MBit: there is a dialog "preparing to move" with a progress bar that moves slowly while the files are moved. I'd prefer a dialog like the one when the files are copied which indicates how much work has been done already.

Ritesh Khadgaray (khadgaray) wrote :

Hi

* gcore/bt dump would be nice to see where nautilus is stuck ( man gcore/man gdb )
* are they both local ( src and dest) ?
* Is nautilus stuck on IO ? what IO wait ( check top o/p)
* Does disabling image preview help ? ( preference->preview )

Cheers
-- ritz

Changed in nautilus (Ubuntu):
status: Confirmed → Incomplete
Launchpad Janitor (janitor) wrote :

[Expired for nautilus (Ubuntu) because there has been no activity for 60 days.]

Changed in nautilus (Ubuntu):
status: Incomplete → Expired
lae krits (laekrits) wrote :

It seems like the files continue to move, at least in some cases. I attempted to refresh the windows and it vanished. The transfer was still successful some minutes later.

Teo (teo1978) wrote :

This shouldn't have been marked as incomplete.

All the tests #7 asks to do he can do himself unless he has tried and been unable to reproduce the issue.

If #7 provided enough instructions for the affected users (i.e. us) to produce the needed information, we could do that, but I don't know what a gcore/bt dump is and I'm not going to read man pages just to figure out what we're being asked to do. Please provide commands to copy and paste. Same for "check top o/p".

Now, to answer the only question that I can answer, i.e. second question in #7, yes, all local in my case.

Changed in nautilus (Ubuntu):
status: Expired → Confirmed
George Politis (gpolitis) wrote :

In my case the move operation successfully completed after a while. But the progress dialog didn't show any progress at all, it appeared completely stuck, which, from a users perspective, can be problemtic. The transfer was over sftp and the file was a few GBs.

Simon (szenger) wrote :

I encounter this bug on a regular basis because i often need to copy/move a large amount of files (several hundreds or even thousands). This is very annoying and should be fixed soon as copying/moving files is a very basic operation of a file manager.

Serah Allison (icarean) wrote :

I have encountered this same bug moving around 1,000 image files between local folders with Ubuntu 15.10. Killing the process, disabling preview (as suggested by khadgaray in comment #7) then trying again made the move nearly instantaneous. Re-enabling preview after the move showed the correct file previews in the new folder immediately. Therefore the problem (for me at least) seems to be entirely in the image preview process).
Package nautilus:
i 1:3.14.2-0ubuntu9.1 vivid-updates

Pieter (diepes) wrote :

Just encountered this, moving 2k small text files, took about 10min.
$ cat /etc/os-release
NAME="Ubuntu"
VERSION="15.10 (Wily Werewolf)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 15.10"
VERSION_ID="15.10"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"

no longer affects: pinguybuilder (Ubuntu)
da2 (hiboudev) wrote :

I have the same bug with an updated Ubuntu 16.04 version.
This kind of bug is unacceptable and shouldn't be there after 3 years.

da2 (hiboudev) wrote :

Another cut/paste of 2 folders containing 1000 images crashed the whole Unity desktop (still Ubuntu 16.04). I had to force computer to turn off, loosing unsaved data.

Testing Ubuntu since some days, that's probably the last days for me. I don't need a modern desktop that can't move files...

Simon (szenger) wrote :

Honestly I simply cannot understand how this bug is already three years old and not even it's importance (current status 'undecided') has been determined yet.

According to https://wiki.ubuntu.com/Bugs/Importance this should be at least a 'medium' importance bug (A bug that has a moderate impact on a core application.) and be treated as such.

teo1978 (teo8976) wrote :

> According to https://wiki.ubuntu.com/Bugs/Importance this should be at least a 'medium' importance bug

It's at least high (severe impact on a [not at all] small portion of users) if not critical: if Nautilus stops responding you are almost forced to kill it, which leaves a random portion of the files moved and the rest unmoved with no easy way to undo or complete the action. That can be considered data corruption.

Lorenzo (lorenzo-cerda) wrote :

Hello everybody,

   I got the same problem. Moving files (once, like 100 files, another one, like 250 files), with Crtl-X Crtl-V, it get stuck in "preparing....". I have Ubuntu 14.04, up to date.

  Let me know it you need any more information.

  All the best,

     Lorenzo

xeddo (xeddo-xeddo) wrote :

Same issue here. Ubuntu 16.04.
Moving 500 images (totalling only 130mb) takes >5 minutes and only shows the "preparing to move" dialogue.
Exact same thing in Thunar takes only a few (~3) seconds!

Tested on a SATA III connected Samsung 840 SSD.
I experienced the same issue across multiple devices with different storage media.

Also it does not matter if it is Drag and Droped or copy and pasted.

Stephen Beres (sbberes-7) wrote :

I have the same problem using a relatively recent install of Ubuntu Gnome 16.04.

transferring files from one directory to another on an internal raid 6 setup. The preparing file transfer dialog will come up and then take forever to complete. If I try to cancel the transfer process the desktop will crash (all desktop icons disappear). If I execute the same mv command from the terminal it completes in mere seconds.

Sebastian (itz-silence) wrote :

I ran into the same issue just now on 15.10 trying to drag <300 text files (<2MB) into a folder. I just received the "preparing ..." pop-up. When I hit cancel after several minutes, a small portion of the files had transfer.

Sebastian (itz-silence) wrote :

Also to add, mine was between local directories. Disabling preview did help significantly, but it still was fairly slow for being mostly text files.

James (roadnutter) wrote :

I still have this bug. It is one of the most frustrating things as we all know that it must be a simple fix. if mv works why does moving large volumes of files graphically have to be so slow. Its faster copying then deleting.

qxu21 (qxu21) wrote :

Confirmed on Mint 17.2 using LXDE's PCManFM. Might not just be Nautilus.

qxu21 (qxu21) wrote :

This was actually happening on Linux Mint LXDE, but there's no option for that.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in pcmanfm (Ubuntu):
status: New → Confirmed
olivier (olivier0101) wrote :

Same bug also. For almost a year now. It drives me crazy.

Simon Vincent (w-sv-y) wrote :

I am seeing the same problem at the moment on Ubuntu 16.04. Moving 1000 jpg files from one directory to another on the same ext4 partition.

Shill Shocked (shillshocked) wrote :

Same problem with Caja on a recently updated version of Arch Linux. Annoying as *$%!.

Francis Chin (chinf) wrote :

Interesting that the last person mentioned Caja - there is potential progress in narrowing down where the problem lies in their issue tracker (https://github.com/mate-desktop/caja/issues/528).

Nautilus, Caja and Nemo all exhibit this same behaviour. In the Caja issue tracker zaps666 suggested that when the problem occurs, dbus (in glib) is waiting for a long time for a notification from somewhere, and that commenting out dbus in the glib move file code fixes the problem, but isn't a solution.

If it's a glib issue, then https://bugzilla.gnome.org is the relevant place for bug reporting; it could also be something to do with the way nautilus uses glib, in which case bugzilla.gnome.org is still the best place to report a bug for nautilus. It's worth having a look there in any case to see if there's already something relevant, as this bug has been around for a while.

I'm constantly getting this problem in Ubuntu 16.04.

Moving 608 jpg files to a sub-folder of the current folder has just taken ages (15 minutes? - certainly long enough for me to find this thread and compose this comment while I was waiting for the move to complete).

The "Preparing to move n files" message very slowly decreases the value of n indicating that there is some progress being made but it should never take this long.

It's getting to the point where I'll always boot into Windows rather than Ubuntu just in case I need to move some files.

nicola dmt (nicola-dmt) wrote :

I experience the same issue when organizing photos. Doing the same operation with mv took approx. 5 seconds, with nautilus 3 minutes.

gummih (gummih) wrote :

We are talking basic file operations in a GUI here. This is 80's stuff.

Autiwa (autiwa) wrote :

Do you need some info, log file or anything else? 4 years after the report, this is still an active bug that completely freeze a copy of files (several dozen of .jpg files in my case and many others).

I'm surprised that this bug is unassigned.

Tobias Weis (tobiweis) wrote :

Is there anything we can do to help fix this, do you need additional info? Or what exactly is the case there has not even been a status update in the last YEARS? Given that this is the most basic functionality and affects _all_ users, I wonder why not even the importance has been set?

Just ran into this issue moving a paltry 48 files. After hanging for five minutes I hit cancel and it continued to hang for another 10 minutes. Now instances of caja can't get directory listings. `caja -q` to shut caja down and now I can get listings again. If I F3 in Caja and drag-and-drop the files, they move instantly.

Affects (at least) 53 people. Status: Confirmed. Importance: Undecided. Assigned to: Unassigned. Makes sense.

ssinfod (ssinfod) wrote :

I also have this problem with Ubuntu 16.04.

uname -a
Linux cpf-dx4840-i3 4.8.0-44-generic #47~16.04.1-Ubuntu SMP Wed Mar 22 18:51:56 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Nautilus 3.14.3

I simply drag and drop files from a folder to another. The folder contains:
(84 PNG (pictures) files of approx. 3 MB and one PDF file (250 MB))

The dialog box shows "Preparing to move N files" (ex: 26)

Then it jams for about 2 minutes...

thanks

Walter Lapchynski (wxl) wrote :

I see no clear test case bug triagers can try to do further research on. I have no information from syslog, dmesg, or any tracing or anything. Is this only with images? What's the minimum number or size? I would this this has something to do with a generic Backend, so we should look for conditions that are universal across all file managers. Please provide this so we can continue researching. If there's no clear way to reproduce, no matter how often this happen or how long it's reported, we cannot fix this.

Changed in nautilus (Ubuntu):
status: Confirmed → Incomplete
Changed in pcmanfm (Ubuntu):
status: Confirmed → Incomplete
Ben (pumrum) wrote :

I just tested this very easily, but unfortunately nothing was recorded in any of the /var/logs. The steps I used to replicate on a Lenovo P50 running Ubuntu Mate 16.04 LTS (fully updated as of 29 March 2017)

1) Open Caja 1.12.7 (also tested using Nautilus on Ubuntu 16.04 LTS)
2) Navigate to a folder that has 500 text files in it of very small size (5-10kb is sufficient)
3) Press F3 to open a new pane (or optionally open a new window, doesn't matter) and navigate to an empty folder on the same drive (or a different drive, doesn't matter)
4) Highlight most or all of the files in the source directory, and press CTRL-X (or edit > cut, doesn't matter)
5) Go to the destination pane, and press CTRL-V (or edit > paste, doesn't matter)

Sometimes, the cut/paste will happen nearly instantly as it should. Sometimes though, it will take a second or two to start, then spend between 1 and 20 minutes sitting there, copying the files one-by-one, very very very very very slowly. This issue is not reproducible using the 'cp' or 'mv' command line programs.

Ben (pumrum) wrote :

Apologies for the double comment - but I realized I missed one of your questions. The size and type of files does not seem to matter. I've had this happen with text, image, video, and "other" files of sizes from a couple kilobytes up to several megabytes. I have not tested with a large number of files of several gigabytes, though I don't imagine it would be as noticeable since one would reasonably expect those to take a bit of time to copy normally.

As far as I can tell there are no definite triggers. When I was first doing a prototype build of Ubuntu 16.04 LTS and ran into this bug, I did a fresh build, updated all packages, and then was able to easily replicate after a clean boot and nothing running except the file browser. My current system uses SSD drives only, but I have also verified on a system with spindle disks.

Ok but can it be less than 500 files? What's the minimum? What versions does this NOT happen on?
--
       @wxl | polka.bike
C563 CAC5 8BE1 2F22 A49D
68F6 8B57 A48B C4F2 051A

Thanks again for taking the time.

It's difficult to say exactly the number at which it occurs because there's a point at which the normal time to copy a small number of files crosses the point where it is no longer normal to copy lots of small files. I can say that I've never _noticed_ it with less than 50 files, but then again - even if it happened with less than 50 files the delay may have been small enough where I didn't realize the issue happened. I've definitely noticed it with as few as 50 files. I did some testing with 20 and 40 files this morning but didn't notice any issue.

This definitely has not occurred in Ubuntu 14.04 using Nautilus 1:3.10.1-0ubuntu8 and previous versions (all the way back to launch). It definitely never happened with Ubuntu 10.04 LTS or 7.04 LTS and any version of Nautilus included in their stable releases.

I'm almost certain it never happened with Linux Mint 17 and Linux Mint 17 MATE, but I can't say that for certain as I abandoned those distros pretty quickly after finding it did not meet my needs.

I don't recall which version of Caja originally shipped with Ubuntu MATE 16.04 LTS, but I installed MATE 16.04 LTS on launch day and keep my packages updated at least weekly, and this issue has been present in all versions.

michal (sirda) wrote :

It just happened to me "Moving file 16 of 21"
Ubuntu 16.04

pchaivaro (pchaivaro) wrote :

Me too

Ferux (ferux-e) wrote :

This bug is just plain ridiculous! I'm making a fool of myself when I try to convince someone that Linux is better! It makes no sense that we have a beautiful UI and can play games on Steam etc if this kind of basic operation fails...

Please fix it or tell me exactly how I should report it to you. I've got this when moving more than 20 files or so, both in Nautilus as Nemo on Ubuntu 16.04.

max (macsym69) wrote :

I experience the same problem with Ubuntu 16.04 on a samsung SSD. My kernel is 4.4.0-79-generic
It happens when I move more than ~100 files even if mv does it immediately! Any clue of what is happening?

levien (levien) wrote :

This is most probably caused by this upstream issue:
https://bugzilla.gnome.org/show_bug.cgi?id=757747

These patches to gvfs should greatly reduce the problem:
https://git.gnome.org/browse/gvfs/commit/?id=0e001c9
https://git.gnome.org/browse/gvfs/commit/?id=fe33512
https://git.gnome.org/browse/gvfs/commit/?id=1224147
https://git.gnome.org/browse/gvfs/commit/?id=57acc80

As I understand, gvfs >1.30.3 should include these patches,
so Ubuntu Zesty 17.04 should suffer much less from this issue.
Can someone verify this?

There are several similar bug reports that may be duplicates:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/388595
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1208993

Simon Quigley (tsimonq2) wrote :

This honestly is an awful bug that I really really want to see fixed.

I'll play with some fixes.

Changed in gvfs (Ubuntu):
assignee: nobody → Simon Quigley (tsimonq2)
status: New → In Progress
Simon Quigley (tsimonq2) wrote :

Attached is a debdiff for Xenial applicable to 1.28.2-1ubuntu1~16.04.1.

description: updated
summary: - cut-n-paste move files got stuck forever
+ [SRU] cut-n-paste move files got stuck forever
Simon Quigley (tsimonq2) wrote :

I have also uploaded my patch to ppa:tsimonq2/universe-upload-testing and have tested it myself, it works 100% as intended from my testing.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in caja (Ubuntu):
status: New → Confirmed
Simon Quigley (tsimonq2) on 2017-08-04
Changed in nautilus (Ubuntu):
status: Incomplete → Confirmed

sponsored.

Changed in gvfs (Ubuntu):
status: In Progress → Fix Released
Changed in gvfs (Ubuntu Xenial):
status: New → Fix Committed
Changed in pcmanfm (Ubuntu):
status: Incomplete → Invalid
Changed in pcmanfm (Ubuntu Xenial):
status: New → Invalid
Changed in nautilus (Ubuntu):
status: Confirmed → Invalid
Changed in nautilus (Ubuntu Xenial):
status: New → Invalid
Changed in caja (Ubuntu):
status: Confirmed → Invalid
Changed in caja (Ubuntu Xenial):
status: New → Invalid
Changed in gvfs (Ubuntu):
assignee: Simon Quigley (tsimonq2) → nobody
Changed in gvfs (Ubuntu Xenial):
assignee: nobody → Simon Quigley (tsimonq2)
Amr Ibrahim (amribrahim1987) wrote :

Update to 1.28.4 in Xenial LP: #1579505.

Amr Ibrahim (amribrahim1987) wrote :

1.28.4 includes the fixing commit.

Simon Quigley (tsimonq2) wrote :

> 1.28.4 includes the fixing commit.

I have just checked, and the new upstream release only contains lp1133477-client-use-sync-methods-instead-of-flushing-dbus.patch, which fixes the Nautilus crash, but doesn't fix the entire bug, which is that file moving is extremely slow with more than a couple of files.

So yes, while it would be helpful to make sure people don't lose data, I still think *all* of these patches are still needed.

Amr Ibrahim (amribrahim1987) wrote :

Simon, you're right. I double checked. It has only one commit out of the four.

Changed in gvfs (Ubuntu Xenial):
importance: Undecided → Critical
Simon Quigley (tsimonq2) on 2017-08-09
description: updated
Robie Basak (racb) wrote :

15:25 <rbasak> tsimonq2: the gvfs fix looks good to me superficially, though I think the surgery involved in the fix deserves a closer review which will take me more time. I'll look again later. Thank you again for driving both of these.

Changed in gvfs (Ubuntu Xenial):
status: Fix Committed → In Progress
Robert Ancell (robert-ancell) wrote :

Given the patches are all upstream commits this looks sane to me. +1.

Hello Teo, or anyone else affected,

Accepted gvfs into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gvfs/1.28.2-1ubuntu1~16.04.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in gvfs (Ubuntu Xenial):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-xenial

Ubuntu MATE 16.04.3

Reproduced the issue in caja using the test case described by tsimonq2.
Installed gvfs/1.28.2-1ubuntu1~16.04.2 (gvfs/xenial-proposed)
Ran killall caja to reload caja and its components.
Attempted to reproduce the bug after reload: could not reproduce the bug.

The proposed package fixes the bug.

tags: added: verification-done-xenial
removed: verification-needed-xenial

Ubuntu MATE 16.04.3 also.

Followed the test case on the Ubuntu MATE forum:

  * https://ubuntu-mate.community/t/help-test-a-critical-bug-fix-in-ubuntu-mate-16-04/14624

I confirm that this update resolves the issue. I've actually been running the fixed version of gvfs on another Ubuntu MATE 16.04.3 computer for about a week. In general use I've encountered no regressions.

Gabriel Dubatti (gdubatti) wrote :

Ubuntu MATE 16.04.3

I followed the instructions from Martin Wimpress and it resolves the issue for me too.
I'll continue testing it.

Stephen Cook (stevecook172001) wrote :

Bug confirmed with me on UM 16.04 LTS 64 bit.

Fix that works can be found here:

https://ubuntu-mate.community/t/help-test-a-critical-bug-fix-in-ubuntu-mate-16-04/14624

Michael Dooley (mdooley) wrote :

Caja bug confirmed Ubuntu MATE 16.04.3 64 bit. After following the test and fix described in https://ubuntu-mate.community/t/help-test-a-critical-bug-fix-in-ubuntu-mate-16-04/14624, the issue is resolved.

Confirming that Simon Quigley's packages here: https://launchpad.net/ubuntu/+source/gvfs/1.28.2-1ubuntu1~16.04.2

Resolve the issue (using the 1024 file transfer method described in the OP).

Ubuntu 16.04 64-bit.

Randy Noseworthy (randynose) wrote :

Ditto:

Confirming that Simon Quigley's packages here: https://launchpad.net/ubuntu/+source/gvfs/1.28.2-1ubuntu1~16.04.2

Resolve the issue (using the 1024 file transfer method described in the OP)..

Bill_MI (bill-mi) wrote :

Upgraded the following packages:
gvfs (1.28.2-1ubuntu1~16.04.1) to 1.28.2-1ubuntu1~16.04.2
Plus 6 dependents

This fixes the problem on Ubuntu-MATE 16.04.
Tested on MATE 1.12.1 an original install.
Tested on MATE 1.16.2 (Martin's PPA)

Bravo!

schiemanski (schiemanski) wrote :

Ubuntu MATE 16.04.3

Followed the test case on the Ubuntu MATE forum too:

  * https://ubuntu-mate.community/t/help-test-a-critical-bug-fix-in-ubuntu-mate-16-04/14624

I confirm that this update resolves the issue. Thanks!

Simon Quigley (tsimonq2) wrote :

This has been verification-done since Comment #61, ignore this. :)

tags: added: verification-done
removed: verification-needed

Ubuntu 16.04.3 here, bug confirmed. With gvfs from proposed, the bug is fixed.

Ferux (ferux-e) wrote :

yes yes YES YES YES!!

Finally fixed on Ubuntu 16.04 with the proposed package.

All credits to Brian and the other persons who finally took this serious and got it solved.

Thank you!

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gvfs - 1.28.2-1ubuntu1~16.04.2

---------------
gvfs (1.28.2-1ubuntu1~16.04.2) xenial; urgency=high

  * Greatly improve file manager performance and fix Nautilus crash by
    backporting four patches (debian/patches/lp1133477-*) from upstream
    (LP: #1133477).

 -- Simon Quigley <email address hidden> Thu, 03 Aug 2017 23:40:48 -0500

Changed in gvfs (Ubuntu Xenial):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for gvfs has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

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.