There is a fix-up for this change waiting to be merged: https://invent.kde.org/frameworks/kconfig/-/merge_requests/134

I am fine with kio implementing things differently as long as the basic functionality keeps working. I used to use Krusader to get images out of my camera and it simply stopped working for me with no obvious indication of what went wrong. This code tries to implement some advanced error handling, yet it is written in a way that it passed a review with a fundamental programming mistake in the basic error handling.

@bruns I find your attitude unnecessarily hostile. If you think that the code is perfect as it is, feel free to patch it case by case until it eventually works for everybody. That is your choice.

I do not think we have to. Please have a look at how attr_copy_fd() from <attr/libattr.h> is implemented: http://git.savannah.nongnu.org/cgit/attr.git/tree/libattr/attr_copy_fd.c?id=a4187bec#n111 This code is quite mature and it is used by cp(1) on GNU/Linux for instance. I do not think that KDE users will appreciate some blindly coded fancy features on top of that when the basic functionality gets totally broken as a result of these experiments. Please keep the code simple and reliable.

The man page says that one has to check return value of the second call. It does not say that the function needs to be called in a loop indefinitely until it succeeds.

Even after applying the proposed patch, the code still looks problematic to me. I would prefer to have it explained first. When fgetxattr(..., 0) returns -1/ERANGE, what is the point of calling fgetxattr(..., 0) again? It is still going to busy-loop indefinitely in this case, doesn't it? How many times do we actually need to call fgetxattr() on a single file descriptor? Twice? Then unbounded loop is not the best construction to begin with.

I was wondering why copying files in Krusader or Dolphin from a vfat-formatted memory card stopped working for me after update. After copying the first file, the transfer stopped progressing and the process ended up consuming 100% CPU forever. Later I discovered that the cause of the breakage was this patch: If fgetxattr() fails with ENOTSUP, the code loops indefinitely calling fgetxattr().