GNOME Bugzilla – Bug 572828
nautilus cannot copy a pack of files bigger than 133.5MB
Last modified: 2009-04-02 01:04:33 UTC
Please describe the problem: I tried many times now, but I cannot copy a set of files in nautilus (from tab to another) that is bigger than 133.5MB. The same thing worked flawlessly in dolphin. Was wondering if there is such a restriction? Steps to reproduce: 1. take two folders, one contains files altogether at least 133MB 2. use two tabs in nautilus to copy 133MB from one tab to the other 3. the "copy" operation always stops at 133MB Actual results: "copy" operation stops Expected results: should just copy all files instead of stop at 133MB Does this happen every time? to me, yes Other information:
And let me add, the nautilus "File operation" seems to crash. E.g. the system tray icon and the copy animation become unresponsive when I reach the 133MB limit.
There's no such thing as a limit of any kind; i tried to reproduce this but doesn't happen here. Are you sure that the source and the destination are perfectly readable and writable with no errors? Does it work if you copy the same files to the same place from a terminal? Does this happen in Nautilus only if you use tabs? We could need a gdb trace of the hang to analyse this properly.
I will try to reproduce it again. The copy destination was a flash drive but it had enough space on it. Maybe I should try other copy operations, but that particular one always stopped at exactly 133MB. Could be that it got hung because of a read-write problem or something like that where dolphin just skipped over. I had the fealing that that particular file operation had crashed. How do I get a gdb trace of that incident?
OK, I tried to do the same operation in the terminal and it worked. I had a couple of occurrences now where a nautilus dialog pops up "File operation" and that crashes and stalls. Same thing just now when I tried to "empty trash" of my flash drive. I would be happy to give you more info on that but there are no error messages given and I don't know how to do a gdb backtrace.
Maybe the title of the bug is misleading since it does not always break down at 133 MB, but it does happen to me once in a while that nautilus "file operations" (when there is a nautilus icon in the system tray) break down when there is a large number of files involved. When I do the same using terminal operations, then it usually works without errors.
When it "hangs" does other nautilus window also stop updating? When this happens, can you attach to nautilus with gdb (gdb attach <pid>) and get a backtrace ("thread apply all bt full" in gdb).
OK, I'll try to get the backtrace next time. Not sure what you mean exactly be your question, I can still do other things in other nautilus windows when that happens, it's just that this particular "File operation" process is frozen. I was wondering if it's because there are some error messages during the copying of files but rsync (in the terminal) did not give me any specific messages when copying the same file package.
there is no particular "File operation" process. Its all the same process. Thats why I asked. So, this means nautilus itself has not hanged, there is just something strange going on in that window. What do you mean by it being "frozen"? Does it not repaint? does it just not make progress?
By "file operation", I meant the new window that pops up and shows the progress (there is also an extra system tray icon with it that is not there if I only have nautilus running). This progress window does repaint, I can move it around and everything. It's just that there is no progress anymore.
I'll try and get a backtrace later tonight (if I can reproduce it).
OK, so I tried again with the same set of files and this time nautilus became completely unresponsive. The process "Stopped" in the system monitor and all nautilus windows went dark. When I do gdb attach <pid> then I only get stuff like this Loaded symbols for /usr/lib/gio/modules/libgiogconf.so Reading symbols from /usr/lib/gtk-2.0/2.10.0/loaders/svg_loader.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/gtk-2.0/2.10.0/loaders/svg_loader.so Reading symbols from /usr/lib/gtk-2.0/2.10.0/engines/libpixmap.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/gtk-2.0/2.10.0/engines/libpixmap.so Reading symbols from /usr/lib/gtk-2.0/2.10.0/engines/libnimbus.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/gtk-2.0/2.10.0/engines/libnimbus.so Reading symbols from /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so Reading symbols from /usr/lib/gtk-2.0/2.10.0/engines/libnodoka.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/gtk-2.0/2.10.0/engines/libnodoka.so (no debugging symbols found) 0x00007f7c24f6b236 in poll () from /lib/libc.so.6 (gdb) Am I missing some developer packages since I have "no debugging symbols found"?
Created attachment 131821 [details] the (gdb) backtrace
OK, so I installed nautilus-dbg. I was wrong in my last post: nautilus turned dark only because I switched on dbg not because the program really crashed. As I said before, nautilus "hangs", ie the copy operation does not make any further progress. I tried to make a backtrace but following the instructions on https://wiki.ubuntu.com/Backtrace was a bit tricky because there was no crash, it only "hangs". Sorry, I don't have so much experience with backtraces. I will attach a file to this report that contains the (gdb) backtrace output. I have no idea if this is really what you are looking for.
Yeah, when you attach to nautilus it will stop the process. So it will stop repainting etc. The interesting part in this is thread 3, which is the one doing the copy:
+ Trace 214077
Thread 3 (Thread 0x42165950 (LWP 19954))
Its hanged while opening a file. Could you install glib-dbg and glibc-debug too? That way we could see which file its hanging on.
glib-dbg and glibc-debug are not in the Ubuntu repos. I tried to install libc6-dbg but it basically gives me the same output as above: (gdb) thread apply all backtrace
+ Trace 214088
Thread 2 (Thread 0x41cb9950 (LWP 12192))
Hi, OK I'm still missing the symbols, have no idea which package they are in in Ubuntu. But I think I can guess the problematic files since it's copying alphabetically. The problematic files are the two "pipes" ~/.icedteaplugin/icedtea-appletviewer-to-plugin ~/.icedteaplugin/icedtea-plugin-to-appletviewer maybe it's because they are not files but pipes (not I would know what a pipe is :)). Note also that if I right-click on these files in Nautilus and choose "Properties" then Nautilus crashes as well. So the problem seems to be that Nautilus cannot handle "pipes" correctly.
Yes, confirmed! If I skip the .icedteaplugin directory, then everything goes through.
*** This bug has been marked as a duplicate of 549298 ***