kdudka added a comment.
There is a fix-up for this change waiting to be merged:
https://invent.kde.org/frameworks/kconfig/-/merge_requests/134
REPOSITORY
R237 KConfig
REVISION DETAIL
https://phabricator.kde.org/D25833
To: davidedmundson, broulik
Cc: kdudka, arojas, broulik,
kdudka added a comment.
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
kdudka added a comment.
@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.
Anyway, strace of `cp --preserve=xattr` on the same device looks
kdudka added a comment.
I do not think we have to. Please have a look at how attr_copy_fd() from
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
kdudka added a comment.
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.
REVISION DETAIL
https://phabricator.kde.org/D17816
To: arrowd, dfaure, chinmoyr, bruns,
kdudka added a comment.
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
kdudka added a comment.
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
