Moving files from one directory to another is extremely slow!

[zaps166]

Use this script to generate files and folders for testing (the script will create "Files" directory which will contain "Dest" directory and 50 empty files. It will automatically open Caja):

#!/bin/bash
mkdir -p Files || exit 1
cd Files || exit 1
for ((i=1; $i <= 50; i++))
do
    touch $i || exit 1
done
mkdir -p Dest || exit 1
exec caja --no-desktop .

1. Run the script.
2. Select all generated files (except the "Dest" directory).
3. Cut selected files (Ctrl+X), don't copy.
4. Open "Dest" directory.
5. Paste files (Ctrl+V) - this operation can take 10 sec. up to 40 sec.! Sometimes it pastes files immediately, so remove all files and test it again.

Tested with 1.12.6 (two computers) and master: ce7cc95

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/32336979-moving-files-from-one-directory-to-another-is-extremely-slow?utm_campaign=plugin&utm_content=tracker%2F651521&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F651521&utm_medium=issues&utm_source=github).

[flexiondotorg]

What distro? What filesystem? Hard disk or SSD? What file manager are you comparing with and how quickly does it perform the same operation? Please provide actual metrics not an estimate.

[zaps166]

Manjaro (Arch Linux), I've compiled Caja from sources (but Mate and GTK and GLib are from Manjaro repo). Tested on HDD and SSD.
CPU and HDD/SSD does nothing during this operation (notice that files generated by test script are empty). It doesn't depend on computer speed - I can compare it to random usleep() on every file.
The time differs, sometimes it is a few seconds (e.g. 10 sec), but sometimes it is 20, 30 or even 40 sec. It is hard to say, I can only create a movie (should I do it?)...

[raveit65]

hmm, i follow your steps to reproduce, pasting the whole files takes about 0.5-1 sec here.
fedora 24 (alpha) with a hardware-raid with 4 ssd using raid0 mode.
Same with another hardware-raid with 4 normal disks in raid10 mode. No difference to previous test.
With a normal external disk connected via slow usb-2.0, not more than 8 or 12 secs.
Well, here i see random differences, but all tests are between those values.
I think those bad timings are because of usb-2.0, and with a slower disk you will see larger fluctuations.
Is your hardware not defect?
Btw. can you confirm your results with another file-manager, ie. nemo, nautilus or thunar?

[zaps166]

Hmm, very strange...
All files are empty in my test, so HDD speed does nothing (it only creates 50 empty files (i-nodes?)). OS also caches files, so sometimes moving is done in RAM and later (on during unmounting) on real media. Please notice that it happens mostly, but not always - the time is also different on every attempt (sometimes also I've got about 1 sec).

And my new results for this test case:

• Caja (gtk2) - almost always slow, sometimes very slow,
• Nemo (gtk3) - same as Caja,
• Nautilus (gtk3) - same as Caja,
• Thunar (gtk2) - always instant (correct behavior),
• PCManFM (Qt5) - always instant (correct behavior),
• Dolphin (KF5/Qt5) - always instant (correct behavior).

If you want to test again please don't cut-back files from "Dest" to "Files", but remove "Files" and create the directory again.
Please retest e.g. 5-10 times on the same machine.

@raveit65 not more than 8 or 12 secs. - too long for 50 empty files :) Even on USB 1.1 (or floppy disk 😄) it should be instant. Of course it happens with many small (non-empty) files, e.g. while moving a lot of songs or photos. Please notice that copying (not moving) files from the test are instant, so why so slow on moving?

... it looks like random sleep, because CPU nor HDD does nothing, but moving 50 files can take up to 40 sec. (sometimes 10 sec, 5 sec or < 1 sec.).

[zaps166]

Tested on Ubuntu 15.10 and Ubuntu's standard file browser - the same problem as in Caja... So it is not exactly a Caja bug, but is it possible to do a workaround in Caja? Moving files is a normal, frequently used operation, so it is not convenient to use another file manager like Thunar or write command line every time :) Moving hundreds or thousands files may take a few minutes or even hours!

problem still exist and got worse on linux mint 18, mate 1.14.0.1, caja 1.14.1. moving files should be instant, not take 5-10min to move files. setup : SSD / and HDD /home /swap, i did not have this problem on mate before 1.12.x, also i noticed that "cut and paste" demands additional space, eg cut-->paste (100gb), you need 200GB of space. 100GB + an additional 100GB to paste. which is not normal... that would be true if it was copy-->paste

[kn00tcn]

i dont have to try your example, i run into this sometimes, i thought it happens more often when files are images & figured it's generating some thumbnail cache

i do not see any cpu usage during this time, no hard drive blinking, it just sits there for a few secs halting at random (some of the files moved, then pauses.... then eventually the rest finish), so it's not the hardware if different software works

it also takes a long time to open a folder with thousands of files, should i make a new issue about that? (i didnt search yet, although maybe the problem is it's scanning the amount of files in subfolders to display in the list view column)

[zaps166]

Unfortunately developers doesn't care about old annoying bugs (and also regressions) :(

Still happens on 1.16.0. Moving files by drag and drop works OK, but Cut->Paste is broken.

Now I've killed Caja on moving a lot of photos (after a few minutes, but it should take milliseconds).

[raveit65]

Unfortunately developers doesn't care about old annoying bugs (and also regressions) :(

I answered but i couldn't reproduce it, please stop to tell lies here 😒

[zaps166]

@raveit65 I also thought about my PRs which are w/o any response for months 😢 (not for Caja, but for panel/applets).

I couldn't reproduce it

My configuration:

• Arch Linux, Caja 1.14.0 GTK2.

hmm, i follow your steps to reproduce, pasting the whole files takes about 0.5-1 sec here.

Sometimes it can take one second, sometimes 30 sec, etc. Sometimes moving hundreds of photos can lock Caja.

Please try this (1000 files):

#!/bin/bash
mkdir -p Files || exit 1
cd Files || exit 1
for ((i=1; $i <= 1000; i++))
do
    touch $i || exit 1
done
mkdir -p Dest || exit 1
exec caja --no-desktop .

Use Ctrl+X and Ctrl+V for moving :) I've killed Caja after 7 minutes, it moves 698 files in 7 minutes. E.g. Thunar can do it in ~1 second, Dolphin (KDE 5) in ~5 seconds.

[lukefromdc]

I've had the problem myself, and it looks like a very old Nauilus bug that nobody has ever fixed. I see this more on moving files than copying them, my video copy jobs normally go OK, but the really ugly case is cleaning two overlapping directories of Debian files. I do this by moving files from one directory into the other, overwriting any copies found there, then moving back. This is very likely to hang outright and force me to kill Caja. No files will be missing or corrupted, all will be in one directory or the other. Still, if I am cleaning directories it pays to back up both of them first.

Copying or moving a whole directory always goes cleanly, it's with a large number of individual files I sometimes get trouble. Copying a newer version of a file onto an older version with the same name in a flash drive (even ONE file) is so nasty I usually delete the older version first, though I've always blamed the flash drives themselves for that.

[zaps166]

Also sometimes (very rare) I've noticed that after successful copying files the windows used to show progress can't close (only killing Caja can close it).

[filosophem]

Hello everyone,

Totally new here. I came across a very similar problem (not to say exactly the same) yesterday while copying 5G of data from one HD to another.

Since I'm not a developper at all, I won't be looking in the code. But maybe with your help, I can set a cron job to log the problem when it occurs (I can try to reproduce it).

Let me know if It's doable

[kn00tcn]

well i was just copying (sometimes moving) over 500GB across different drives twice without a problem

yet moving a set of 350 jpgs from one folder to another on the same drive resulted in getting stuck... couldnt browse new folders in other caja windows, couldnt open a new caja window, the stop button still took a couple minutes for anything to happen & eventually the multiple new caja windows opened up after the progress window closed

i resumed the move now, let's time it:

after 2m10s: 130 items remaining
2m11s: 103 items
4m20s: 102
4m30s: 45
5m00s: 44
5m25s: 43
5m40s: 24
5m41s: done

(to add to this annoyance, i was on an external this time, stupid WD sets it to park after only 6secs of no activity, i was playing loosely encoded videos earlier, but this time i had an mp3 playing, which buffered like 10secs at a time, so the drive kept parking & unparking, i wouldnt have been able to traverse in caja back to the videos folder to stop it from parking)

so maybe one thing more important than this bug is to have file operations in a new process like windows has for explorer (good way to not worry about the desktop/tray going down if one of the explorer windows crashes, if you remember to enable it, off by default)

[zaps166]

@kn00tcn Exactly this bug :)

stupid WD sets it to park after only 6secs of no activity

sudo hdparm -B 255 /dev/sdX (X is the letter of hard drive; Docs)