I encountered a serious bug on moving files from one folder to another
with standard "Files" application in Gnome. Namely, when the number of
files in the distination folder is about 4,500, the "Files" application
deadly hangs, and only restaring the system helps. The files are mainly
pdf documents, the total amount is about 10 Gb.

Sorry if I'm posting to the wrong list, I couldn't use the reportbug
program.

Linux corvax 6.1.0-37-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.140-1 (2025-05-22) x86_64 GNU/Linux


Thanks,

Andrew Makhorin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Jul 11, 2025, Andrew Makhorin wrote:

I encountered a serious bug on moving files from one folder to another
with standard "Files" application in Gnome. Namely, when the number of
files in the distination folder is about 4,500, the "Files" application deadly hangs, and only restaring the system helps. The files are mainly
pdf documents, the total amount is about 10 Gb.

How long did you leave it before rebooting?
What type of drives are the source / target? Spinning Rust? SSD? NVMe?
How are they connected? SATA? USB?


--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmhwUQcACgkQbWVw5Uzn KGC8Zg/8D1w3N71DmFgc1SG7ieuSQCxSeDnzSNiLvQI0ilIHplY/aMK090J7fR2a 45wSx2h5RCHQdM4zGjTPrUvS0gtkCjJH4SpfE+d+GJZfY293nleTSvm802EaTmsR cFf4ieOJDDW0FaVXBQeAGMMppPOj/TWqShw7uHWLDLM1+1zjc8tsDvRdJtxwIzGM yumFWh7jBT/6jkVhg48xFpqYWlgQ6f/Y3cBsIHXHZWIgeFxC1bS/Qu7y/YR85ab/ oe3y3h8WbCK4uye8PNfxobVuFT64OBlfW+oKoDFkF0Wf2MrlvQn01iDEWj3B0/br cECZte/AFlTlnJvswpYVFHplE+ltBnJPBlprtofVVO5Hv9JPJx/vnTBTJJqEaeqM qltLUPSWlsKVrk3Vo3izH/Og4DEwPnA/NTjzcPzJXSWL9nQQJ/Eu+V2TxSR1Kwsd vBlr2nCbQ38fuW/qsMJ4n3VJDqUyUifRWeGzbFSXJ4nUfDZ9tSgbsSLRRsjyskkM JEi8amVwk/EYGsuA3N2eGKcbfJbG+goxs6NwnBorkvrDa5H+NjrE5VjqDmR5K5f0 QqFHEj4IZOeXtbET8fsqCaMD+V25hFSCr5hrEFPeNyEJM+QFotvjFWF/QTQqAj2e MOO133nFcm42j6aXYW/ArbW8/woQxrnfyyPzseHUApX/cbRgIsQ=
=loTL
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us

On Jul 11, 2025, Andrew Makhorin wrote:

I encountered a serious bug on moving files from one folder to another
with standard "Files" application in Gnome. Namely, when the number of files in the distination folder is about 4,500, the "Files" application deadly hangs, and only restaring the system helps. The files are mainly pdf documents, the total amount is about 10 Gb.

How long did you leave it before rebooting?

The bug appears spontaneously, sometimes in 30 minutes, sometimes in 5 mins.

I'm not sure 100%, however, I think the bug is somehow related to displaying  the destination folder contents during moving the files.

What type of drives are the source / target? Spinning Rust? SSD? NVMe?

Both source and destination folders are on the same 500 Gb SSD, ext4 FS.

How are they connected? SATA? USB?

SATA.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Jul 11, 2025, Andrew Makhorin wrote:

On Jul 11, 2025, Andrew Makhorin wrote:

I encountered a serious bug on moving files from one folder to another with standard "Files" application in Gnome. Namely, when the
number of files in the distination folder is about 4,500, the
"Files" application deadly hangs, and only restaring the system
helps. The files are mainly pdf documents, the total amount is
about 10 Gb.

How long did you leave it before rebooting?

The bug appears spontaneously, sometimes in 30 minutes, sometimes in 5
mins.

Sorry, I meant how long do you let the system keep chugging along after
it appears to hang?

I'm not sure 100%, however, I think the bug is somehow related to displaying�the�destination folder contents during moving the files.

What type of drives are the source / target? Spinning Rust? SSD? NVMe?

Both source and destination folders are on the same 500 Gb SSD, ext4 FS.

OK, same drive means the entire process is going to be serial; basically
this series of steps is pretty much what's going on:

1. Open file for reading
2. Read to cache
3. Close file
4. Open file for writing
5. Write from cache
6. Close file
7. Go back to step 1

And that's ignoring all the "other I/O" the disk is needing to do.
Doesn't help any that file open/close is more expensive than just reading/writing a handle that's already open.

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmhw5rIACgkQbWVw5Uzn KGC1mg/8DQxsB7zP+qobKSdS9oV1KzZfzyH/3x2WCxtEgkCPpLgj3sG5xcCRagPw 07HvhVMgCmRY/Go4CvZiKrgGScIgRTpP2E9YmJ82656ie7ZtFWt5biq8ErZnny5E AUWz9IG3EEPkvsZDjCYNST2+kZOawnCOOcDQv5e2fuXWG/odUObfMcPlnRiuv65r skOiABGcTZfuPs9g8QhRKbLqcoX6gScn2faPio6eiK8RwrkHVsdFjesLLexRsxO2 3SvQ4tOQtB/E6BX4pKcHgzM3xtm6quzdbMCYlSg6hDMqOeN7k9dWsyNy0wjSCA7F 11wqKp7/l9A+xGfT98D4YwJKaoPimLNxq4tdMUFhjJ9A85SPWZr/BoI6hLnsX7qz cGftRg2GX6QH5w0PIM7L9hyVhMTa74afNKqJHzGo80zk/vy1+Yrv5eetEjiW6J36 gjGABwZxbilB4bIzO2E1ji6N8QdQVbLpiothQOz3mctzS90zZbO3tbX39wXr9TjU VS3kor8ZQxafRLS4dNd6/QDaRIRQXiESCF9m52Dfvh3kYGfWcyYzt21WqDp8r1p5 5F/BuLF5RSi5BloxXCyk0l9I8U+jlQWLgNIK9vtArxGuhcLAPivFLZeYj4f1n/8O HvbQL9Skz1Pi6y1iDkC7GoYUmez+XZtZ02MvbX0HbVxbBjElmYQ=
=fFbn
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us

mick.crane wrote:

When moving files on the same disk impression is, at least with dragging in the desktop file manager, it seems instant. Whereas to another disk seems to make new files. I guess that when on the same disk the OS changes only something about the file description?

That's often, but not always, correct.

If the target location is in the same filesystem as the source
of the files, the only thing that needs to be changed is the
metadata about where each file is.

If the target location is on a different filesystem, a "move" is
a full copy followed by a delete of the source.

Multiple filesystems can be on the same physical storage (root, home,
var...), and single filesystems can span multiple physical storage units
(RAID of various kinds).

-dsr-

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Jul 11, 2025 at 13:39:44 +0100, mick.crane wrote:

When moving files on the same disk impression is, at least with dragging in the desktop file manager, it seems instant. Whereas to another disk seems to make new files. I guess that when on the same disk the OS changes only something about the file description?

Essentially, yes, this is correct. The key here is whether the file is
moving to a different file system, or to a different directory within
the same file system.

If the file is moving within the same file system, then the *data*
don't have to be copied. Only the directory listings that point to
the data have to be updated.

If the file is moving to a different file system, then the data have to
be copied over, in addition to updating the directory listings on both
file systems, and then finally marking the storage space as available
for use on the original file system.

Even if the two file systems are on the same physical disk, a move of
a file from one file system to the other will still entail a full copy.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sorry, I meant how long do you let the system keep chugging along after
it appears to hang?

The system itself remains working. The "Files" window gets dark and doesnt  response, and it's impossible to close it.

When moving files on the same disk impression is, at least with dragging in  the desktop file manager, it seems instant. Whereas to another disk seems
to make new files. I guess that when on the same disk the OS changes only  something about the file description?

Sure. However in this case the destination folder contents is also displayed in a window, and it is updated every time new files arrive. I think the bug  is related just to displaying the folder contents.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Jul 11, 2025, mick.crane wrote:

On 2025-07-11 10:52, Andrew Makhorin wrote:

On Jul 11, 2025, Andrew Makhorin wrote:

I encountered a serious bug on moving files from one folder to
another with standard "Files" application in Gnome. Namely,
when the number of files in the distination folder is about
4,500, the "Files" application deadly hangs, and only restaring
the system helps. The files are mainly pdf documents, the total
amount is about 10 Gb.

[...]

What type of drives are the source / target? Spinning Rust? SSD? NVMe?

Both source and destination folders are on the same 500 Gb SSD, ext4 FS.

When moving files on the same disk impression is, at least with
dragging in the desktop file manager, it seems instant. Whereas to
another disk seems to make new files. I guess that when on the same
disk the OS changes only something about the file description?

You're correct -- when "moving" files around on the same filesystem, the
hard link is what gets moved, rather than the actual file data. As I
recall, hardlinks have a negligible size, but you're still up against
"reading the old link / writing the new link / deleting the old link"
for 4k files, plus journaling, plus DE (and/or filemanager) behavior.

I should've been clearer on that (remember folks, don't post without the morning coffee first :) ).

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmhxEWgACgkQbWVw5Uzn KGDLvA/8CPsNiuGgTx47Rwua9g3vC6pNgDyORDdooqfbydEiTfH52nmjBp5RbrRT 6hcDaDuKxBQGmcYuF+jtbaqgqns2Aq5rEeJ1ROAZvU6Rc1FIyr0zdhjlBRpjBdK+ 83BSU8AwiodoSP2QDFMzdf5DNDXVMFWnnJop1bFC1+VXWCZSfa9A0YwT3D7B0ZD7 d9QJZWmbZQO9tUbUAEbJyB5d9MKExWuvk424Bu0QjZ9S+DO1re9BHXrYmCRz6+f/ dDrQ7DqIWp2PXzt19JJWDv+XDYnrN47CDJHvrLukxEcitlrbX8TpxUOowB4Rn32Q eDD+FLIZAktMsOLUet25E/CisWwyc/lo8hK91zzz3VcLLwLbVtVhxda4HckMnfFl KDv6A0yl6nN6MOYah2os6sNpHlKDbBA2cN+JkameGmXVxnjABZ5Z+PemG6cB+1Qj X2E7tTTS0YIX0Qt/qwJE0/7Daj/DPdzXu7DqFRe3w4tiefmCe2OqDCo6xhIZ/HEj UpeJ2MVXNqkA1kBXazAo6OXAUZzmePz3siDaFoWudL3mcHdZWe3kUmCeJv5nPoKX jyrWrPWU5B5J0zAJcn5ZpOyAcSF0Sk16w08TZFbc4B7IgKpcjp1LEzWpfJVUgh6/ VgIlI7uuH/oCqS/AfrVdKnL1prVKGOgyY0Baqhac9KsBkc9MWGM=
=1w2J
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us

Greg (HE12025-07-11):

On 2025-07-11, Dan Ritter <[email protected]> wrote:

If the target location is on a different filesystem, a "move" is
a full copy followed by a delete of the source.

Is that true?

Yes, absoltely.

If the source is deleted as part of the process it's no longer a "copy."

Indeed. And you might notice it is exactly what Dan said.

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Greg wrote:

On 2025-07-11, Nicolas George <[email protected]> wrote:

Greg (HE12025-07-11):

On 2025-07-11, Dan Ritter <[email protected]> wrote:

If the target location is on a different filesystem, a "move" is
a full copy followed by a delete of the source.

Is that true?

Yes, absoltely.

If the source is deleted as part of the process it's no longer a "copy."

Indeed. And you might notice it is exactly what Dan said.

Does that mean to a different filesystem on the same disk it's a move rather than a copy?

No. Same filesystem, regardless of disk: move. Different
filesystem, regardless of disk: copy+delete.

-dsr-

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Greg (HE12025-07-11):

Does that mean to a different filesystem on the same disk it's a move rather than a copy?

The fact that it is on the same disk is not relevant. Apart from that, I suggest you re-read Dan's mail more carefully, everything was in it.

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Jul 11, 2025, Nicolas George wrote:

Greg (HE12025-07-11):

Does that mean to a different filesystem on the same disk it's a move rather
than a copy?

The fact that it is on the same disk is not relevant. Apart from that, I suggest you re-read Dan's mail more carefully, everything was in it.

It was? Pretty sure I made at least a few hand-wavey errors of omission
at the very least ... ?




--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmhxJ98ACgkQbWVw5Uzn KGAE3g/+MIhRFthqrr7d8QzqjJg1+U8NnUx2vHxVy2B7+EjMql/n3yHMoj31HMwZ 1ETr/7iYwsmM6fKE0v+5wiaRzsSH6lF+50oiAX/OXZOdsUQJWBUH6nyxR+XEa7bL lmlKbNUEn+LX5bHkDViI3lduOg6Zg87z/pN0/pQCAbb5hwhu8T4pnIhGb/5LRQ6a cuTsWpmA2Zx+vEmRJNauVVMddyQ2GPa850ta+BgpuNdnDo7z5CoQEVMCgvFelfUb fCvB+kxaJRwydQurNdz8owvDYxNM3bH8wpcRxmlpm8urChssoj5FLHAGn33kcBKT L5fy2XPopeVXqUhxt/kfZgAjyvLHsk4vJaVCx7l+jgu6pyeU/jmHI/ducfkEuXBi 8zhAdKLDS/Z16EN8tHlShyqmtPtFbdNIfAZ+AUD1ldYrGbgKy7UzDPs+sXbUVpgR Zf3nnTJEr1j3JejMbP1LwcgD6dZf/DEqNZYoELC8AGA/t7LRzpywfQrIsFcvjPVR KDp1kpXKOD/JFwOLk4raFtwZSMJiQ0OPmFdlfMHI9oCdstYGWbjjk23u8S0xxszS xEPbefc7RZD1vqaU9nECKvwmA6tzzHznvqXwOXO9Uzn821235PxPQZB0V17ra84C 1Vjloh8UG/PNoAMQ9GUAuy6TVWArMzHVs8ekqOH8xoaz8Vqu/gk=
=i25f
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us

Dan Purgert wrote:

On Jul 11, 2025, Nicolas George wrote:

Greg (HE12025-07-11):

Does that mean to a different filesystem on the same disk it's a move rather
than a copy?

The fact that it is on the same disk is not relevant. Apart from that, I suggest you re-read Dan's mail more carefully, everything was in it.

It was? Pretty sure I made at least a few hand-wavey errors of omission
at the very least ... ?

Me Dan, not you Dan.

Feel free to call me dsr to disambiguate, many do.

-dsr-

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11 Jul 2025, at 16:45, Dan Ritter <[email protected]> wrote:

Dan Purgert wrote:

On Jul 11, 2025, Nicolas George wrote:
Greg (HE12025-07-11):

Does that mean to a different filesystem on the same disk it's a move rather
than a copy?

The fact that it is on the same disk is not relevant. Apart from that, I >>> suggest you re-read Dan's mail more carefully, everything was in it.

It was? Pretty sure I made at least a few hand-wavey errors of omission
at the very least ... ?

Me Dan, not you Dan.

Feel free to call me dsr to disambiguate, many do.

I wonder if this is a UNIX thing. I’ve been jmd since my first UNIX account in 198something. My auld dad was jcd a decade or two before then.

J

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Jul 11, 2025, Dan Ritter wrote:

Dan Purgert wrote:

On Jul 11, 2025, Nicolas George wrote:

Greg (HE12025-07-11):

Does that mean to a different filesystem on the same disk it's a move rather
than a copy?

The fact that it is on the same disk is not relevant. Apart from that, I suggest you re-read Dan's mail more carefully, everything was in it.

It was? Pretty sure I made at least a few hand-wavey errors of omission
at the very least ... ?

Me Dan, not you Dan.

Oh good, I can go back to not worrying people think I know what I'm
talking about :D

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmhxQ/EACgkQbWVw5Uzn KGCXIxAArWsgaJaQERP/kxqSbKukyqHdPfco+p+k5nmogeInSrx13V5kBLbj4y+9 V0skYQh+SeR5OQ2HYTVwzfelMsrB/q/c57v8Y6zDqVJSaLG0KwegGS8yteZ8oj9G 2sksBEngKd2+vtWy1HLOLfaHMaQLRQeyLIhCzc17Zg6Qo1vnghacvpZgqz3ICtcE 4QJ4HPyjeGBruuTNZiNvueR3T61R1/ZPcSwtsDcpayPlZ9CtXUrwdkKPX0JsjRpR 5py/dletSa3+KOTcXO0I1ObwrWrg+1/IpbrslW0YPuW/NkPKfxyR+VcGRDtO5K93 vqZHkWeb8rnerIuw2W52+FCxYbfMuVIGyZfDhCunzYY/J7BPdbRqllqw+VtW+YvY zoI4eMs2fnYn/jEEeMZe+87e8/qTXqAXSOZxnPwA4aPpaUYCSpjzFrWqMt+f/Ddm 9RfNXK1dsniTlJ6EF7mxLtf9X/h/SqAxV9s3f/M/QV3UOnWqS/yMrpvMUtOBETrT 1hv00SZU3zFxC84qIc32x99RmqAO1/xRxn7IZAjTvJU5XVqOFhiHAwKa2cpXC2IE YEFkP80GV4UQt31ngTOhMqm2lN5OXBmqnw+KpmV2+cOGWgHr6tJubFrcezEe8E6V 6GlVDP2d+e+3sxR4b1jYELZVRYcKTtzPy4uv2lBWRpnYQvuYu6k=
=RX1R
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us