Solved Dolphin requires good eyes.

skunk

skunk

I am encountering a very serious problem with FreeBSD 13.0-p7.
I created a ZFS pool to sort old data (downloads etc).
When I move files from a subdirectory to its parent directory, the files are not being moved to the parent directory, but into other subdirectories, apparently randomly, I haven't found a particular pattern yet.
When I do ll, these subdirectories' entry count is then increased accordingly.
When I do ll <thissubdirectory>, I get an error "No such file or directory".
zpool scrub has not found any issues.

I have never experienced such a thing before, as I still use FreeBSD 12.2 on my main computer.
The other computer with the problems mentioned is the computer I want to replace my old computer with.
Of course, the data on the ZFS pool mentioned is now quite trashed; I think I will have to redo all the work :(

Now I am unsure how to proceed.
Is it advisable to use FreeBSD 13 again at all?
Or is it better to ditch FreeBSD 13 and continue using FreeBSD 12, which still has real FreeBSD ZFS? Does FreeBSD 12.3 still have real FreeBSD ZFS?

I have created the ZFS pool in question with some extra features enabled, and I am not sure whether the problem is OpenZFS in general, or only occurs if particular features are enabled.
As I will have to do again all the work of moving the data from the old backups, I would rather prefer to do that in a "safe" way, so I don't have to repeat this work of a few days a third time.
Any suggestions/advice how to proceed?
 
It also might be a Dolphin issue, it could have copied the subdirectories' contents into some other subdirectory instead of the directory itself.
But I find still strange that directories show a lot of entries and when I try to list them, they seem not present/empty. I guess I'll have to take a break and a coffee.
 
I now think I might have found out the problem, it might be dolphin related: on 12.2 files moved into another directory land into that directory if being dropped on an area outside of a file/directory name.
On 13 they seem sometimes to land in a subdirectory even if being dropped outside of the file/directory name. Will have to investigate more...
 
dolphin is some kind of graphical file manager?
First thing I would do is open a terminal and try the process from the command line.
I've done the move files around by command line on a FreeBSD-13 system without issues, so it's likely a dolphin issue.
 
skunk said:
move
Click to expand...

skunk said:
copied
Click to expand...

How, exactly?


Here, no problem with a basic drag-and-drop move.

Screen recording (loops after output from ll):

2022-03-09 12-58.gif


Code: 
% pkg -vv | grep -e url -e enabled
    url             : "http://pkg0.bme.freebsd.org/FreeBSD:14:amd64/latest",
    enabled         : yes,
    url             : "https://alpha.pkgbase.live/current/FreeBSD:14:amd64/latest",
    enabled         : no,
    url             : "file:///usr/local/poudriere/data/packages/main-default",
    enabled         : yes,
% pkg info -x x11-fm/dolphin
dolphin-21.12.3
% zfs version
zfs-2.1.99-FreeBSD_g17b2ae0b2
zfs-kmod-v2022021400-zfs_9f734e81f
% grep zfs_load /boot/loader.conf
zfs_load="NO"
openzfs_load="YES"
% pkg info -x openzfs
openzfs-2022021400_1
openzfs-kmod-2022021400
% uname -aKU
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #5 main-n253627-25375b1415f-dirty: Sat Mar  5 14:21:40 GMT 2022     root@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1400053 1400053
%
 
I cannot understand how GUI File Manager can break the file system? It works with API, not with raw access to blocks. Test the same with UFS.
 
I first thought it was ZFS, but it seems to be an issue of Dolphin (when used with two panes) that the target does not get highlighted, like it gets in Windows, for example.
So if you move files from one pane to the other, there is no clear indication where they will be written to. The only "surefire" way to prevent them landing in some subdirectory seems to drop them on other files' lines.
I will post a PR on KDEs bugzilla, requesting that target [directories] get highlighted when the mouse is over their respective area, so the user gets a visual feedback that prevents to make mistakes.
 
skunk said:
I will post a PR on KDEs bugzilla, requesting that target [directories] get highlighted when the mouse is over their respective area, so the user gets a visual feedback that prevents to make mistakes.
Click to expand...
I just checked and can confirm that if you drag and drop a file or directory from one Dolphin window to another (split, not seperate windows), if you hover over a directory it does get highlighted to show where it will go.
 
Well, I have no idea why this does not happen on my computer. Graphics driver? Other DE/WM running than KDE? Will have to check whether highlighting works when KDE Plasma is active.
 
The computer has ECC memories, so there should be a NMI in case of error.

Edit: I actually do not feel well when working with computers without ECC. Undetected bit flips and the like lead to data rot, which is often noticed only much later. Had all that in the past.
 
dave01 said:
… (split, not seperate windows), if you hover over a directory it does get highlighted to show where it will go.
Click to expand...

skunk for me, the change in appearance, before the drop, does occur however it is barely perceptible:

2022-03-09 15-10.gif

  • for the targeted folder, contrast decreases (the dark outline of the folder icon becomes lighter).

YMMV. What are your appearance preferences?

Can you share a screen recording, with some test files and test directories?

(I used multimedia/peek to record and produce the animated GIFs.)


My current preferences include:
  • Breeze Light colours (the default)
  • Wimbledon Plasma style (Plasma theme)
1646839062702.png
 
I think grahamperrin may be onto something. Themes and colors (colours) are under the control of the user and programs changing them dynamically can be "odd".
Take this forum: my colors cause this thread to have a white background. If I use the mouse and highlight some text in this post, the highlight is barely visible. I'm sure themes and color stuff would make it more visible.

So I'm going to guess that it's a problem with dolphin, maybe not a true "bug" but rather a useability enhancement.
 
Regarding KDE, I haven't started it yet, so I guess the settings are "factory default".
I use FVWM, KDE "runtimes" are being started in .xinitrc before FVWM: kbuildsycoca5 --noincremental; kded5&

Probably my eyes are too bad, I cannot notice the change in appearance grahamperrin mentioned.
I would rather have expected the target to be inverted, like on Windows for example.
If I understand you correctly, then there is some barely perceptible change, and what needs to be done on KDE side is to make this better visible.
Thank you, that will help a lot for writing the PR on the KDE bugzilla :)
 
I looked again and then tried the same on my computer... yes, now I see it... the dark outline of the folder icon changes to a little lighter, but I need to look very carefully and close to notice at all. I'd call it ultra-low-contrast... I need high contrast :(
Completely different to what I was accustomed with older KDE, MacOS and Windows... there it was/is very noticeable. Inverting or flashing the folder name text is still the best imho...!
Hope the KDE guys will have an idea how to improve that...
 
Moving files by drag&drop is bad thing in my opinion. There is risk to drop in wrong folder, etc. (especially with mouse with bad quality/condition). Under Windows I always prefer to use Ctrl-X/Ctrl-V or Cut/Paste from context menu. If I remember correctly, in early Windows versions there was option to enable confirmation dialog before drag&drop copy/move.
 
You must log in or register to reply here.
Back
Top