SUMMARY Configuring the default view settings for folders that have no individual view settings doesn't work anymore currently, custom settings for the default view seem to be just getting ignored by Dolphin. STEPS TO REPRODUCE 1. Open Dolphin (build from master, or e.g. boot live image of openSUSE Krypton). 2. Default view mode is "Symbols". 3. Create a fresh test folder, and fill it with content (an empty file is sufficient). 4. Go to the folder above your test folder. 5. Enable menu bar (Ctrl+M) 6. Enable "Settings -> Configure Dolphin -> View -> Remember display style for each folder" 7. Open "View -> Adjust View Display Style..." 8. Set "View mode" to "Details" and check "Use as default view settings", click OK. 9. Go to the test folder. OBSERVED RESULT View mode of test folder is still set to "Symbols", despite "Details" was configured in the steps before. EXPECTED RESULT View mode of test folder should be "Details", respecting the default view settings made before. SOFTWARE/OS VERSIONS KDE Plasma Version: 6.2.80 KDE Frameworks Version: 6.9.0 Qt Version: 6.8.0 ADDITIONAL INFORMATION Reproduced with: * Dolphin build from master with kdesrc-build * Dolphin from openSuse Krypton current live image running in a VM.
Confirmed on git-master Dolphin Operating System: Solus 4.6 KDE Plasma Version: 6.2.80 KDE Frameworks Version: 6.9.0 Qt Version: 6.7.3 Kernel Version: 6.11.5-307.current (64-bit)
(In reply to Jan Rathmann from comment #0) > SUMMARY > Configuring the default view settings for folders that have no individual > view settings doesn't work anymore currently, custom settings for the > default view seem to be just getting ignored by Dolphin. Seems indeed like we might be saving view properties even for folders for which an explicit view mode has never been set. The fix would be to not save anything for them.
Seems the "Use as default view settings" sets the default settings for the current folder only. It doesn't propagate to any new folders or such. In fact the setting is not even saved. When you toggle the checkbox, click ok and open the view settings again, the checkbox is off again.
A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/870
*** Bug 497405 has been marked as a duplicate of this bug. ***
The patch fixes the issue for me.
*** Bug 497461 has been marked as a duplicate of this bug. ***
Git commit 8d155558e980197b4dc2180660ea9bc61a23f3d3 by Méven Car, on behalf of Akseli Lahtinen. Committed on 16/12/2024 at 19:00. Pushed by meven into branch 'master'. ViewProperties: Return nullptr if viewPropertiesString is empty If viewPropertiesString is empty, return a nullptr. This will later used in the stack by the defaultProperties call. In defaultProperties, if we can't find the global directory, create new one with a tempfile. If tempfiles can't be created, use default instead. This will ensure that view settings are saved and loaded correctly if user has separate view properties per folder. This will also add an unit test, where we create a global directory, modify it and make sure the changes are reflected in the unmodified folder. M +69 -6 src/tests/viewpropertiestest.cpp M +39 -20 src/views/viewproperties.cpp https://invent.kde.org/system/dolphin/-/commit/8d155558e980197b4dc2180660ea9bc61a23f3d3
Git commit 86609f89358243c08ebe4de8498a0fa6dff8370e by Akseli Lahtinen. Committed on 16/12/2024 at 20:52. Pushed by akselmo into branch 'release/24.12'. ViewProperties: Return nullptr if viewPropertiesString is empty If viewPropertiesString is empty, return a nullptr. This will later used in the stack by the defaultProperties call. In defaultProperties, if we can't find the global directory, create new one with a tempfile. If tempfiles can't be created, use default instead. This will ensure that view settings are saved and loaded correctly if user has separate view properties per folder. This will also add an unit test, where we create a global directory, modify it and make sure the changes are reflected in the unmodified folder. (cherry picked from commit 8d155558e980197b4dc2180660ea9bc61a23f3d3) 97d9a70c ViewProperties: Return nullptr if viewPropertiesString is empty 60a3da35 Create lambda for creating temporary files Co-authored-by: Akseli Lahtinen <akselmo@akselmo.dev> M +69 -6 src/tests/viewpropertiestest.cpp M +39 -20 src/views/viewproperties.cpp https://invent.kde.org/system/dolphin/-/commit/86609f89358243c08ebe4de8498a0fa6dff8370e
*** Bug 497583 has been marked as a duplicate of this bug. ***
*** Bug 497622 has been marked as a duplicate of this bug. ***
*** Bug 497628 has been marked as a duplicate of this bug. ***
*** Bug 497672 has been marked as a duplicate of this bug. ***
*** Bug 497729 has been marked as a duplicate of this bug. ***
*** Bug 497754 has been marked as a duplicate of this bug. ***
*** Bug 498013 has been marked as a duplicate of this bug. ***
*** Bug 497936 has been marked as a duplicate of this bug. ***
I have this issue again after updating to Plasma 6.3 Beta. I'm using Dolphin 24.12.1. Was the patch merged?
The issue I have is not exactly the one described here, but some of the ones marked as duplicates. By default I have "Details view mode" and no "show preview of files and folders". If I go to any directory and I change the view to "Icons view only" and enable the previews, this is not saved. Other changes are saved, but not this particular one. For example, just changing the view mode to "icon view only" does work, if done alone. Should I create a new bug report or can we reopen this one?
(In reply to Iyán Méndez Veiga from comment #19) > By default I have "Details view mode" and no "show preview of files and > folders". If I go to any directory and I change the view to "Icons view > only" and enable the previews, this is not saved. Other changes are saved, > but not this particular one. For example, just changing the view mode to > "icon view only" does work, if done alone. I cannot reproduce this with Dolphin build from master today - can you provide more detailed steps what you are doing exactly?
I have the exact same problem. The bug has not been solved.
Heres my info from the previous bug i submitted: SUMMARY Essentially, when I have "Per folder view settings" enabled ("Remember display style per folder"), if I change the view settings to something other than default (ie: Details -> Icons), it will reset back to default if I leave the folder and re-enter it. This issue is prevented if I also change another setting from default (ie: sort by name -> sort by modified). I have reproduced this result multiple times. I don't know all the settings that are affected, but changing the sort mode always fixes the issue. STEPS TO REPRODUCE 1. Set "Remember display style per folder" in preferences. 2. Change only the View Mode in a folder. 3. change directories to some other folder 4: Return to modified folder OBSERVED RESULT Folder reverts to default view mode. EXPECTED RESULT Folder view mode is the same as set previously. SOFTWARE/OS VERSIONS KDE Plasma Version: 6.2.4 KDE Frameworks Version: 6.9.0 Qt Version: 6.8.1 Kernel Version: 6.12.7-arch1-1 (64-bit) ADDITIONAL INFORMATION I recently installed this system so I don't have data for previous versions of Dolphin.
Yeah, something is wrong in the fix. I can reproduce exactly what BananasGoMoo described, except that his workaround does not work in my case (the show previews is not correctly saved). So here are my steps to reproduce my issue as well: 1. Go to Dolphin settings -> View -> General and select "Use common display style for all folders" 2. Now go to your home folder and change view to "Details view mode" and disable "Show preview of files and folders" 3. Go back to settings and now select "Remember display style for each folder" 4. Enter any folder and change view to "Icons view mode" and enable "Show preview of files and folders" 5. Exit that folder and enter again Expected result: Folder remember the view mode and that preview is enabled Actual result: Details view mode is used and no previews
@Iyán Méndez Veiga and BananasGoMoo: Weird, I still was not able to reproduce it when following your steps. According to the KDE Gear changelog, the fix is included in Dolphin 24.12.1. @BananasGoMoo: What version of Dolphin are you using?
Heres my info from the previous bug i submitted: SUMMARY Essentially, when I have "Per folder view settings" enabled ("Remember display style per folder"), if I change the view settings to something other than default (ie: Details -> Icons), it will reset back to default if I leave the folder and re-enter it. This issue is prevented if I also change another setting from default (ie: sort by name -> sort by modified). I have reproduced this result multiple times. I don't know all the settings that are affected, but changing the sort mode always fixes the issue. STEPS TO REPRODUCE 1. Set "Remember display style per folder" in preferences. 2. Change only the View Mode in a folder. 3. change directories to some other folder 4: Return to modified folder OBSERVED RESULT Folder reverts to default view mode. EXPECTED RESULT Folder view mode is the same as set previously. SOFTWARE/OS VERSIONS KDE Plasma Version: 6.2.4 KDE Frameworks Version: 6.9.0 Qt Version: 6.8.1 Kernel Version: 6.12.7-arch1-1 (64-bit) ADDITIONAL INFORMATION I recently installed this system so I don't have data for previous versions of Dolphin.(In reply to Jan Rathmann from comment #24) > @Iyán Méndez Veiga and BananasGoMoo: > > Weird, I still was not able to reproduce it when following your steps. > > According to the KDE Gear changelog, the fix is included in Dolphin 24.12.1. > > @BananasGoMoo: What version of Dolphin are you using? I have updated to 24.12.1 that is available in the standard Arch repo. My current KDE info is as follows (the pervious message was from my bug filed earlier this week): KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.9.0 Qt Version: 6.8.1 Kernel Version: 6.12.8-arch1-1 (64-bit) Graphics Platform: Wayland
Also can't reproduce on Arch Linux's stable release
(In reply to Damglador from comment #26) > Also can't reproduce on Arch Linux's stable release What kind of additional files or information can I provide that will assist here?
(In reply to Damglador from comment #26) > Also can't reproduce on Arch Linux's stable release What kind of additional files or information can I provide that will assist here? btw my bug is Bug #498013
"Common display style for all folders" and "Remember display style for each folder" use their own different set of settings. > 1. Go to Dolphin settings -> View -> General and select "Use common display style for all folders" > 2. Now go to your home folder and change view to "Details view mode" and disable "Show preview of files and folders" > 3. Go back to settings and now select "Remember display style for each folder" > 4. Enter any folder and change view to "Icons view mode" and enable "Show preview of files and folders" > 5. Exit that folder and enter again I followed these steps and couldn't get the bug to happen. When using "Remember display style for each folder", did you use "Current folder and sub-folders" or "All folders" + "Use as default view settings" items when applying?
(In reply to Akseli Lahtinen from comment #29) > "Common display style for all folders" and "Remember display style for each > folder" use their own different set of settings. > > > 1. Go to Dolphin settings -> View -> General and select "Use common display style for all folders" > > 2. Now go to your home folder and change view to "Details view mode" and disable "Show preview of files and folders" > > 3. Go back to settings and now select "Remember display style for each folder" > > 4. Enter any folder and change view to "Icons view mode" and enable "Show preview of files and folders" > > 5. Exit that folder and enter again > > I followed these steps and couldn't get the bug to happen. When using > "Remember display style for each folder", did you use "Current folder and > sub-folders" or "All folders" + "Use as default view settings" items when > applying? When I select "Remember display file for each folder", there are no sub-options. I see nothing like "current folder and sub folders" or "all folders"
Btw I am looking in Configure Dolphin -> View -> General
(In reply to Akseli Lahtinen from comment #29) > "Common display style for all folders" and "Remember display style for each > folder" use their own different set of settings. > > > 1. Go to Dolphin settings -> View -> General and select "Use common display style for all folders" > > 2. Now go to your home folder and change view to "Details view mode" and disable "Show preview of files and folders" > > 3. Go back to settings and now select "Remember display style for each folder" > > 4. Enter any folder and change view to "Icons view mode" and enable "Show preview of files and folders" > > 5. Exit that folder and enter again > > I followed these steps and couldn't get the bug to happen. When using > "Remember display style for each folder", did you use "Current folder and > sub-folders" or "All folders" + "Use as default view settings" items when > applying? I don't think I understand what you mean by this. I don't see any different options when I select any of the two options under "Display style". By the way, I must add (because I just realized) that I cannot replicate the issue in all directories, but only on some. Probably this explains why you are not able to replicate the issue. If I figure out what is different about the two directories I will let you know here.
I think BananasGoMoo by mistake changed this to fixed.
Akseli Lahtinen, can you please clarify your last comment. We both didn't understand what option you meant. By the way, where does Dolphin store view options for the different folders when a .directory file is not used?
Here is a short video showing one particular example of the issue: https://drive.switch.ch/index.php/s/T5TYfewH5xMNvMu In the folder ~/Pictures/Wallpapers, the view settings are correctly saved, but in ~/Documents, they are not. I was not able to find what might trigger the issue in only some directories. Also, once I find a particular directory where I can replicate the issue, moving that directory around does not fix it either. For example, I have one folder in ~/Desktop where settings are not saved. If I move it to the root of my home folder ~/, the issue remains.
Just to be sure the issue is not caused by some of my user's settings, I created a new user, started Plasma there I can replicate the exact same issue on the Documents folder.
(In reply to Iyán M. V. from comment #33) > I think BananasGoMoo by mistake changed this to fixed. I think it was set by the person who replied to us, as when I posed it was already set to 'fixed - needs more info' prior to me posting. But yes, it seems as if they have a setting we do not have.
(In reply to Iyán M. V. from comment #34) > Akseli Lahtinen, can you please clarify your last comment. We both didn't > understand what option you meant. > > By the way, where does Dolphin store view options for the different folders > when a .directory file is not used? I'm not the person you asked, but if you look at dolphin's settings, when you select the option we're talking about, it says that the folder view settings are saved in extra metadata inside the folder structure itself, not as a separate file. if it can't add the extra metadata (ie: filesystems that do not support it) it will make a .directory file
(In reply to BananasGoMoo from comment #38) > I'm not the person you asked, but if you look at dolphin's settings, when > you select the option we're talking about, it says that the folder view > settings are saved in extra metadata inside the folder structure itself, not > as a separate file. if it can't add the extra metadata (ie: filesystems that > do not support it) it will make a .directory file Thanks for the hint! I totally missed that. So I think the bug is affecting Dolphin to save this metadata in the filesystem. If I do getfattr -d <directory> I see that some have saved the view properties in user.kde.fm.viewproperties, but the ones affected by the bug don't. For example, If I change the view of Documents like I do in the video to "Icons view mode" but without enabling the preview, this attribute is added: user.kde.fm.viewproperties#1="[Dolphin]\012AdditionalInfoV2=Details_Size,Details_Date,CustomizedDetails\012PreviewsShown=false\012Timestamp=2025,1,19,12,31,45.418\012Version=4\012" If in addition I enable the preview, user.kde.fm.viewproperties is gone.
If I manually set the extended attribute Dolphin respects it, and the folder is shown both in icons mode and with the preview enable. setfattr -n "user.kde.fm.viewproperties#1" -v "[Dolphin]\012AdditionalInfoV2=Details_Size,Details_Date,CustomizedDetails\012PreviewsShown=true\012Timestamp=2025,1,19,12,31,45.418\012Version=4\012" Pictures/Wallpapers Hopefully, this narrows it down a bit to find the issue in the source code.
(In reply to Iyán M. V. from comment #40) > If I manually set the extended attribute Dolphin respects it, and the folder > is shown both in icons mode and with the preview enable. > > setfattr -n "user.kde.fm.viewproperties#1" -v > "[Dolphin]\012AdditionalInfoV2=Details_Size,Details_Date, > CustomizedDetails\012PreviewsShown=true\012Timestamp=2025,1,19,12,31,45. > 418\012Version=4\012" Pictures/Wallpapers > > Hopefully, this narrows it down a bit to find the issue in the source code. Thank you for shedding some light. Two things. Why can't dolphin write to metadata ? Has the folder a lot of metadata already ? (There is size limit for xattr) Dolphin may output some errors in the console if launch from there. Secondly should this fail dolphin would store the view properties in ~/.local/share as fallback and this seems to not work. So that's a different than the one originally reported here.
(In reply to Méven Car from comment #41) > (In reply to Iyán M. V. from comment #40) > > If I manually set the extended attribute Dolphin respects it, and the folder > > is shown both in icons mode and with the preview enable. > > > > setfattr -n "user.kde.fm.viewproperties#1" -v > > "[Dolphin]\012AdditionalInfoV2=Details_Size,Details_Date, > > CustomizedDetails\012PreviewsShown=true\012Timestamp=2025,1,19,12,31,45. > > 418\012Version=4\012" Pictures/Wallpapers > > > > Hopefully, this narrows it down a bit to find the issue in the source code. > > Thank you for shedding some light. > > Two things. > Why can't dolphin write to metadata ? Has the folder a lot of metadata > already ? (There is size limit for xattr) I think it can write without issues, but for this particular combo of "Icon view + Preview" the metadata is erased. Directories where I observed this issue don't have any other metadata, so I think I'm quite far from the xattr size limit for values (which for ext4 is the block size if I'm not wrong? In my case this would be 4096 bytes). Note also that with a git bisect, this particular issue started with the fix: https://invent.kde.org/system/dolphin/-/commit/86609f89358243c08ebe4de8498a0fa6dff8370e So I'm confident this is a Dolphin issue and unrelated to my particular filesystem. > Dolphin may output some errors in the console if launch from there. This is what I get when opening Dolphin from a console: qt.gui.imageio: libpng warning: iCCP: known incorrect sRGB profile (many identical lines removed) kf.kio.core.connection: Socket not connected QLocalSocket::PeerClosedError kf.kio.core: An error occurred during write. The worker terminates now. qt.gui.imageio: libpng warning: iCCP: known incorrect sRGB profile (many identical lines removed) kf.kio.core.connection: Socket not connected QLocalSocket::PeerClosedError kf.kio.core: An error occurred during write. The worker terminates now. kf.kio.core.connection: Socket not connected QLocalSocket::PeerClosedError kf.kio.core: An error occurred during write. The worker terminates now. QObject::killTimer: Timers cannot be stopped from another thread QObject::~QObject: Timers cannot be stopped from another thread QObject::killTimer: Timers cannot be stopped from another thread QObject::~QObject: Timers cannot be stopped from another thread > Secondly should this fail dolphin would store the view properties in > ~/.local/share as fallback and this seems to not work. I have a few entries there (mostly for run/media paths), but none for local directories where I can trigger the issue. > So that's a different than the one originally reported here. Yes, I agree. What we are discussing now it's not exactly as the description of this particular bug, but others "more related" were marked as duplicates of this one. Should I open a new issue summarizing all we know so far and close this one instead?
Created attachment 177548 [details] screenshot of view properties menu (In reply to Iyán M. V. from comment #34) > Akseli Lahtinen, can you please clarify your last comment. We both didn't > understand what option you meant. > Sorry, I forgot to reply. If you have Settings -> View -> Remember Display style for each folder, then adjust the view display style, these items should pop up. I think I misread the original comment, so you can disregard that question.
(In reply to Akseli Lahtinen from comment #43) > Created attachment 177548 [details] > screenshot of view properties menu > > (In reply to Iyán M. V. from comment #34) > > Akseli Lahtinen, can you please clarify your last comment. We both didn't > > understand what option you meant. > > > > Sorry, I forgot to reply. If you have Settings -> View -> Remember Display > style for each folder, > then adjust the view display style, these items should pop up. > I think I misread the original comment, so you can disregard that question. You mean when I change it in a specific folder? When I do that, it just changes. No message pops up about it.
(In reply to BananasGoMoo from comment #44) > (In reply to Akseli Lahtinen from comment #43) > > Created attachment 177548 [details] > > screenshot of view properties menu > > > > (In reply to Iyán M. V. from comment #34) > > > Akseli Lahtinen, can you please clarify your last comment. We both didn't > > > understand what option you meant. > > > > > > > Sorry, I forgot to reply. If you have Settings -> View -> Remember Display > > style for each folder, > > then adjust the view display style, these items should pop up. > > I think I misread the original comment, so you can disregard that question. > > You mean when I change it in a specific folder? When I do that, it just > changes. No message pops up about it. Try to reproduce the bug, launching dolphin from the terminal (all dolphin windows must be closed prior): QT_LOGGING_RULES="org.kde.dolphin.debug=true" dolphin This should give us some output to work with.
(In reply to Méven from comment #45) > (In reply to BananasGoMoo from comment #44) > > (In reply to Akseli Lahtinen from comment #43) > > > Created attachment 177548 [details] > > > screenshot of view properties menu > > > > > > (In reply to Iyán M. V. from comment #34) > > > > Akseli Lahtinen, can you please clarify your last comment. We both didn't > > > > understand what option you meant. > > > > > > > > > > Sorry, I forgot to reply. If you have Settings -> View -> Remember Display > > > style for each folder, > > > then adjust the view display style, these items should pop up. > > > I think I misread the original comment, so you can disregard that question. > > > > You mean when I change it in a specific folder? When I do that, it just > > changes. No message pops up about it. > > Try to reproduce the bug, launching dolphin from the terminal (all dolphin > windows must be closed prior): > QT_LOGGING_RULES="org.kde.dolphin.debug=true" dolphin > > This should give us some output to work with. Alright, when I did that, this is the message I got: bananasgomoo@ArchBanana ~ % QT_LOGGING_RULES="org.kde.dolphin.debug=true" dolphin org.kde.dolphin: Saving view-properties to "/home/bananasgomoo/.local/share/dolphin/view_properties/local/" kf.kio.core.connection: Socket not connected QLocalSocket::PeerClosedError kf.kio.core: An error occurred during write. The worker terminates now. kf.kio.core.connection: Socket not connected QLocalSocket::PeerClosedError kf.kio.core: An error occurred during write. The worker terminates now. This is on an ext4 internal drive but it also has a problem on my exFAT external drive.
Any updates on this? Were you able to check my log?
(In reply to BananasGoMoo from comment #47) > Any updates on this? Were you able to check my log? Yes but they aren't that helpful. org.kde.dolphin: Saving view-properties to "/home/bananasgomoo/.local/share/dolphin/view_properties/local/" Should be org.kde.dolphin: Saving view-properties to "/home/bananasgomoo/.local/share/dolphin/view_properties/local/home//Document" Unless you were changing the view settings for path root /. Do you experience the issue on all folders or only specific ones ? What does the log says if you change folders and change some view settings. > This is on an ext4 internal drive but it also has a problem on my exFAT external drive. Those are two cases, different case exfat does not support xattr IIRC, ext4 does and should allow it unless you have some specific setting. We have unit-test for this case. I certainly don't reproduce: ``` STEPS TO REPRODUCE 1. Set "Remember display style per folder" in preferences. 2. Change only the View Mode in a folder. 3. change directories to some other folder 4: Return to modified folder OBSERVED RESULT Folder reverts to default view mode. EXPECTED RESULT Folder view mode is the same as set previously. ``` so there is something particular with the way you do things or your setup. Can you be specific with the path of folders you tested. And test in different folders, in "~/New Folder" for instance. It could be your mount/filesystem options. Please share `mount` output. The original bug is fixed (three people confirmed the fix), your case is more specific it seems and Iyán M. V. share the same setup. But most people wouldn't.
(In reply to Méven from comment #48) > I certainly don't reproduce: > ``` > STEPS TO REPRODUCE > 1. Set "Remember display style per folder" in preferences. > 2. Change only the View Mode in a folder. That's not enough to trigger the bug. Change the View Mode AND enable/disable the previews. > 3. change directories to some other folder > 4: Return to modified folder > > OBSERVED RESULT > Folder reverts to default view mode. > > EXPECTED RESULT > Folder view mode is the same as set previously. > ``` > The original bug is fixed (three people confirmed the fix), your case is > more specific it seems and Iyán M. V. share the same setup. > But most people wouldn't. The fix actually causes the bug for me doing a git bisect.
(In reply to Méven from comment #48) > (In reply to BananasGoMoo from comment #47) > > Any updates on this? Were you able to check my log? > > Yes but they aren't that helpful. > > org.kde.dolphin: Saving view-properties to > "/home/bananasgomoo/.local/share/dolphin/view_properties/local/" > > Should be > > org.kde.dolphin: Saving view-properties to > "/home/bananasgomoo/.local/share/dolphin/view_properties/local/home// > Document" > > Unless you were changing the view settings for path root /. In that case yes, I was changing it in root. Here is the output for home/documents: qt.gui.imageio: libpng warning: iCCP: known incorrect sRGB profile qt.gui.imageio: libpng warning: known incorrect sRGB profile qt.gui.imageio: libpng warning: iCCP: known incorrect sRGB profile qt.gui.imageio: libpng warning: known incorrect sRGB profile org.kde.dolphin: Saving view-properties to "/home/bananasgomoo/Documents" qt.gui.imageio: libpng warning: iCCP: known incorrect sRGB profile qt.gui.imageio: libpng warning: known incorrect sRGB profile qt.gui.imageio: libpng warning: iCCP: known incorrect sRGB profile qt.gui.imageio: libpng warning: known incorrect sRGB profile > Do you experience the issue on all folders or only specific ones ? > What does the log says if you change folders and change some view settings. It happens on all folders, on both my ext4 and on the exfat i mentioned, but all my examples have been from ext4. Nothing comes up in the log when i change folders. all that comes up is the message when it tries to save view settings (when I change the view settings). > > This is on an ext4 internal drive but it also has a problem on my exFAT external drive. > > Those are two cases, different case exfat does not support xattr IIRC, ext4 > does and should allow it unless you have some specific setting. I don't know what settings I would have enabled. I only modified settings available in the GUI. > We have unit-test for this case. > > I certainly don't reproduce: > ``` > STEPS TO REPRODUCE > 1. Set "Remember display style per folder" in preferences. > 2. Change only the View Mode in a folder. > 3. change directories to some other folder > 4: Return to modified folder > > OBSERVED RESULT > Folder reverts to default view mode. > > EXPECTED RESULT > Folder view mode is the same as set previously. > ``` > > so there is something particular with the way you do things or your setup. > Can you be specific with the path of folders you tested. > And test in different folders, in "~/New Folder" for instance. > > It could be your mount/filesystem options. Please share `mount` output. > > The original bug is fixed (three people confirmed the fix), your case is > more specific it seems and Iyán M. V. share the same setup. > But most people wouldn't. my mount output is as follows: proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) dev on /dev type devtmpfs (rw,nosuid,relatime,size=32697560k,nr_inodes=8174390,mode=755,inode64) run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755,inode64) efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) /dev/nvme0n1p2 on / type ext4 (rw,relatime) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64) cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot) pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=40,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=3393) hugetlbfs on /dev/hugepages type hugetlbfs (rw,nosuid,nodev,relatime,pagesize=2M) mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime) debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime) tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime) tmpfs on /run/credentials/systemd-journald.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,size=1024k,nr_inodes=1024,mode=700,inode64,noswap) configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime) fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime) tmpfs on /tmp type tmpfs (rw,nosuid,nodev,size=32707372k,nr_inodes=1048576,inode64) /dev/nvme0n1p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime) tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=6541472k,nr_inodes=1635368,mode=700,uid=1000,gid=1000,inode64) portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000) gdrive: on /home/bananasgomoo/Cloud/GDrive type fuse.rclone (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000) /dev/sda1 on /run/media/bananasgomoo/My Book type exfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro,uhelper=udisks2) for the above, the only one i configured manually was the original FS of the system when I installed it (root directory, boot), Google Drive (rclone), and my external HDD (sda1). everything else was configured either automatically by Arch or KDE. Here are some various folders I have tested in: / /home/bananasgomoo/Documents/Ventoy/ /dev/ /home/bananasgomoo/Documents/FloppyDrive Stuff/ /home/bananasgomoo/Pictures/ /etc/ so basically various kinds of issues. but actually, just as I was re-testing to give some answers I discovered a new part of the issue. If i set the view mode to "compact mode", it saves it properly alone, without changing other settings. it is only an issue of I try to set "Icons Mode" so is there something that works differently with those 2 buttons? I am using the GUI toolbar
also maybe theres a more detailed debug mode? if theres something more verbose i could debug better.
Alright, I've discovered the issue. To reproduce this issue - 1: Have the setting enabled "Remember Display Style for each folder" 2: Have the default view as "details" mode 3: Go to any particular folder (ie ~/Documents) 4: use the UI Toolbar button to change the UI mode to "Icons" 5: change folder to somewhere else 6: return to original folder This does not apply to using "compact mode" view This also does not apply if you use Menu -> More -> View -> Adjust View Display Style using that menu properly changes it even without changing other settings. So this seems to be a slightly different issue than the original.
(In reply to BananasGoMoo from comment #52) > Alright, I've discovered the issue. > > To reproduce this issue - > 1: Have the setting enabled "Remember Display Style for each folder" > 2: Have the default view as "details" mode > 3: Go to any particular folder (ie ~/Documents) > 4: use the UI Toolbar button to change the UI mode to "Icons" > 5: change folder to somewhere else > 6: return to original folder > > This does not apply to using "compact mode" view > This also does not apply if you use Menu -> More -> View -> Adjust View > Display Style > using that menu properly changes it even without changing other settings. > > So this seems to be a slightly different issue than the original. For me with these steps, documents still stays as icons view, as expected. I set the default view to details from view mode settings first and applied it to all folders. Then i followed your steps.
(In reply to Akseli Lahtinen from comment #53) > (In reply to BananasGoMoo from comment #52) > > Alright, I've discovered the issue. > > > > To reproduce this issue - > > 1: Have the setting enabled "Remember Display Style for each folder" > > 2: Have the default view as "details" mode > > 3: Go to any particular folder (ie ~/Documents) > > 4: use the UI Toolbar button to change the UI mode to "Icons" > > 5: change folder to somewhere else > > 6: return to original folder > > > > This does not apply to using "compact mode" view > > This also does not apply if you use Menu -> More -> View -> Adjust View > > Display Style > > using that menu properly changes it even without changing other settings. > > > > So this seems to be a slightly different issue than the original. > > For me with these steps, documents still stays as icons view, as expected. > > I set the default view to details from view mode settings first and applied > it to all folders. > > Then i followed your steps. Maybe Its the way the default view mode was set? I have never actually used More -> View -> adjust view display style for anything except for testing here. The original way I set the default view mode for all folders, is by setting "Use common display style for all folders" in settings, changing the view to "details" and then switching it to "different display views per folder" after that. so maybe doing it that way never properly initializes the folders? I'm not sure but that's the only difference in our steps I can see.
Ah yes, that way I get what you mean. So if I: 1. have "Use common display style for all folders" 2. change display to details 3. change setting to "Remember display style for each folder" What this does is it utilizes the old setting you may have set for the folder. The correct way to make sure all folders use same display style is from the Adjust view display style menu: 1. set it to your liking 2. apply to "All folders" and/or check the "use as default view settings" 3. click OK This makes sure the metadata that is used by dolphin gets updated. The Use common display style for all folders uses different metadata for this to make sure if you switch between the settings, the old settings wont disappear. So to me it sounds like people have been relying on a bug that has been fixed.
(In reply to Akseli Lahtinen from comment #55) > (...) > So to me it sounds like people have been relying on a bug that has been > fixed. I think what you are describing is something else. Please read all previous comments. For me the real issue here is that Dolphin is, uncertain certain conditions (which are not easy to replicate for some, apparently), complete erase all the filesystem attributes, when it shouldn't. And this wrong behavior started with the patch for the original issue, after doing a git bisect. Please, check again my video (if you haven't already) where you can clearly see that what happens is not me "relying on a bug" as a feature: https://drive.switch.ch/index.php/s/T5TYfewH5xMNvMu
I agree, this is not expected behavior. It doesn't say anywhere that it will totally remove all previously set data. These folders are properly set if I use the button in combination with other settings, but if I only change it from details to icons it should respect my setting, whether I have set the default view using the button or using the view menu. Therefore it is a bug.
Additionally, it properly overrides my previous settings when i switch to using a shared view, so clearly it understands what I want my default to be.
I've tested the various related behaviors described in this issue, and am not able to replicate any of them with Dolphin 24.12.1 or built from today's git-master. The main two: 1. The original issue of custom settings not being saved 2. Iyán said Dolphin is also erasing all filesystem attributes incorrectly, which he believes started with a patch for the original issue (discovered via git bisect) ## TESTING SUMMARY Testing with 24.12.1 Original issue: not able to reproduce Some folders misbehave but not others (Iyán): not able to reproduce Steps from comment #23: not able to reproduce Erased attributes issue (using ~/Documents): not able to reproduce Steps from comment #52: not able to reproduce Testing with git-master Original issue: not able to reproduce Some folders misbehave but not others (Iyán): not able to reproduce Steps from comment #23: not able to reproduce Erased attributes issue: not able to reproduce Steps from comment #52: not able to reproduce
I'm a little concerned how this issue is so hard to reproduce, as I am using essentially stock KDE with stock Dolphin. I have done nothing special whatsoever and I have only modified the settings listed in this issue. All other settings are default, except that I have added additional preview renderers for various file types. I have changed my default starting directory to home, instead of last opened folders. Other than that I believe my entire installation of Dolphin is default. I have installed this fresh, as I have installed this OS fresh as of December 14th, 2024. Whatever version of dolphin was available at the time is what I was using. This has been 100% reproducible for me 100% of the time since I started using this PC. I have no reference for before this period as I was not consistently using Linux as my main OS prior to this. I am not using any testing versions of KDE, or of system components. I would be happy to provide any other debug logs if I can produce them. Are there any more verbose logging modes for dolphin?
btw for reference here's a video of me reproducing the issue: https://drive.google.com/file/d/1KM1xRaeXmCDoWlgmPLCwrDTzHFEYJBMZ/view?usp=drive_link
To shed some light, affected people could you run and report the results of commands : getfattr -d ~/Documents And generally the folder concerned, after you have set non-default settings, and after you load the folder and reproduce the issue. The command may return nothing and that would be informative. And getfattr -d ~/.local/share/dolphin/view_properties/global cat ~/.local/share/dolphin/view_properties/global/.directory When you have changed the default settings (that's where they are stored). The .directory file isn't supposed to be present. I will probably add verbose traces to dolphin, so that after a future release we will have more to work with. > I'm a little concerned how this issue is so hard to reproduce, as I am using essentially stock KDE with stock Dolphin. I have done nothing special whatsoever and I have only modified the settings listed in this issue. All other settings are default Don't be, as you have seen this requires some unknown conditions for the bug to manifest. The fact that you have a fresh install and most people aren't has probably to do with it or at least partly. Be patient please and diligent please, I am very much frustrated be assured.
(In reply to Méven from comment #62) > To shed some light, affected people could you run and report the results of > commands : > > getfattr -d ~/Documents > > And generally the folder concerned, after you have set non-default settings, > and after you load the folder and reproduce the issue. > The command may return nothing and that would be informative. Prior to and after setting *just* the view setting to Icons, the output is nothing. if I also set "sort by -> modified" in addition to Icons view I get the following: getfattr: Removing leading '/' from absolute path names # file: home/bananasgomoo/Documents user.kde.fm.viewproperties#1="[Dolphin]\012SortRole=modificationtime\012Timestamp=2025,2,6,18,20,16.384\012Version=4\012ViewMode=1\012" after resetting the sort by back to "name" (my default setting), the command once again returns nothing. so it is actively removing the attributes if only the view mode is changed. > And > > getfattr -d ~/.local/share/dolphin/view_properties/global > cat ~/.local/share/dolphin/view_properties/global/.directory > > When you have changed the default settings (that's where they are stored). > The .directory file isn't supposed to be present. getfattr -d ~/.local/share/dolphin/view_properties/global outputs the following: getfattr: Removing leading '/' from absolute path names # file: home/bananasgomoo/.local/share/dolphin/view_properties/global user.kde.fm.viewproperties#1="[Dolphin]\012Timestamp=2024,12,27,16,53,28.468\012Version=4\012ViewMode=1\012" as expected, the .directory does not exist: cat: /home/bananasgomoo/.local/share/dolphin/view_properties/global/.directory: No such file or directory > I will probably add verbose traces to dolphin, so that after a future > release we will have more to work with. that would be great. i feel like things are failing that arent being reported in the current debug. or maybe branches not being triggered. > > I'm a little concerned how this issue is so hard to reproduce, as I am using essentially stock KDE with stock Dolphin. I have done nothing special whatsoever and I have only modified the settings listed in this issue. All other settings are default > > Don't be, as you have seen this requires some unknown conditions for the bug > to manifest. The fact that you have a fresh install and most people aren't > has probably to do with it or at least partly. > Be patient please and diligent please, I am very much frustrated be assured. reminds me of that recent issue with fonts of GTK apps where the change in cache variables caused text to not display on people who's cache wasnt updated recently lol
(I send the output for ~/Pictures/Wallpapers, which works on my laptop, but not on my PC, instead of ~/Documents, but otherwise exactly same issue). Here are the outputs using Dolphin 24.12.1. Happy to repeat with latest commit, or the previous commit before it breaks for me, if you think might help. $ getfattr -d ~/.local/share/dolphin/view_properties/global (Nothing) $ cat ~/.local/share/dolphin/view_properties/global/.directory [Dolphin] PreviewsShown=false Timestamp=2024,5,30,18,18,29.12 Version=4 ViewMode=1 (Before doing anything) $ getfattr -d ~/Pictures/Wallpapers (Nothing) (Changing View Mode to Icons view mode) $ getfattr -d ~/Pictures/Wallpapers # file: Pictures/Wallpapers/ user.kde.fm.viewproperties#1="[Dolphin]\012PreviewsShown=false\012Timestamp=2025,2,6,10,28,28.576\012Version=4\012" (Enabling Show preview of files, after having changed the view mode) $ getfattr -d ~/Pictures/Wallpapers (Nothing) (Starting all over, this time only enabling show preview of files) $ getfattr -d ~/Pictures/Wallpapers # file: Pictures/Wallpapers/ user.kde.fm.viewproperties#1="[Dolphin]\012Timestamp=2025,2,6,10,31,12.817\012Version=4\012ViewMode=1\012" Btw, I think I mentioned it before, but I can manually edit the attribute with the following command: $ setfattr -n "user.kde.fm.viewproperties#1" -v "[Dolphin]\012PreviewsShown=true\012Timestamp=2025,2,6,10,28,28.576\012Version=4\012" Pictures/Wallpapers And Dolphin now shows both Icons and Previews.
I must add that my installation is not fresh at all, I've been using this at least for 2 years now (so this particular PC started with Plasma 5.x). I have done some cleaning in the past in ~/.config, though.
(In reply to Méven from comment #62) > getfattr -d ~/.local/share/dolphin/view_properties/global > cat ~/.local/share/dolphin/view_properties/global/.directory > > When you have changed the default settings (that's where they are stored). > The .directory file isn't supposed to be present. I'm curious about this. It is present on my system. I will try to remove it and report back.
Okay, so after removing it, and saving the settings again. $ cat ~/.local/share/dolphin/view_properties/global/.directory (Does not exist anymore, it was not recreated) $ getfattr -d .local/share/dolphin/view_properties/global # file: .local/share/dolphin/view_properties/global user.kde.fm.viewproperties#1="[Dolphin]\012PreviewsShown=false\012Timestamp=2025,2,6,10,40,46.67\012Version=4\012ViewMode=1\012" Issue remains for me.
Some thought after reading a bit the source code. I think the issue might come from a bug in the logic of when to store settings, and when not. It should check if settings in that folder differ from the global ones, not the default ones from Dolphin. These are my global settings, saved by configuring Dolphin to "use common display style for all folders", modifying the settings to my like (i.e., details view, no previews) and then changing back to "remember display style for each folder" $ getfattr -d ~/.local/share/dolphin/view_properties/global # file: home/iyan/.local/share/dolphin/view_properties/global user.kde.fm.viewproperties#1="[Dolphin]\012PreviewsShown=false\012Timestamp=2025,2,6,22,18,9.49\012Version=4\012ViewMode=1\012" Since PreviewsShown=false there, I would expect that any directory with PreviewsShown=true should store this in the filesystem attributes or in the .directory file. Same goes for ViewMode. It should only be stored if it differs from ViewMode=1. What I noticed is that these global settings are ignored, and (I guess?) default's Dolphin ones are used instead. For example, if I changed ~/Pictures/Wallpapers to details view mode. $ getfattr -d Pictures/Wallpapers user.kde.fm.viewproperties#1="[Dolphin]\012PreviewsShown=false\012Timestamp=2025,2,6,22,48,53.577\012Version=4\012ViewMode=1\012" Notice that there are two things wrong here: PreviewsShown=false should not be saved, and ViewMode=1 should not be saved. If I enable previews, then $ getfattr -d Pictures/Wallpapers user.kde.fm.viewproperties#1="[Dolphin]\012Timestamp=2025,2,6,22,50,8.382\012Version=4\012ViewMode=1\012" Again, wrong, because PreviewsShown=true should be saved! And what happens when I changed both to Icons view and show previews? Bingo! $ getfattr -d Pictures/Wallpapers (Nothing!) When it should, instead, have saved both PreviewsShown=true and the view mode... In the source code, the attributes are deleted because boolean allDefault (line 534 in current master) gets set to true. Hope this helps someone more familiar with Dolphin source code. If I'm not wrong above (which maybe I am...), I don't understand why is so hard to reproduce the issue...
Here is another video using the latest commit from master, and also trying the suggestion from Akseli Lahtinen about using the "correct way" to change these settings from the "Adjust view display style" menu. I tried to make it very obvious that it is only the "Icon view mode" + "Show previews" combo, the settings that causes an issue. https://drive.switch.ch/index.php/s/QEFirMnm9hKag3X
(In reply to Iyán M. V. from comment #68) > Some thought after reading a bit the source code. I think the issue might > come from a bug in the logic of when to store settings, and when not. It > should check if settings in that folder differ from the global ones, not the > default ones from Dolphin. > > These are my global settings, saved by configuring Dolphin to "use common > display style for all folders", modifying the settings to my like (i.e., > details view, no previews) and then changing back to "remember display style > for each folder" > > $ getfattr -d ~/.local/share/dolphin/view_properties/global > # file: home/iyan/.local/share/dolphin/view_properties/global > user.kde.fm. > viewproperties#1="[Dolphin]\012PreviewsShown=false\012Timestamp=2025,2,6,22, > 18,9.49\012Version=4\012ViewMode=1\012" > > Since PreviewsShown=false there, I would expect that any directory with > PreviewsShown=true should store this in the filesystem attributes or in the > .directory file. Same goes for ViewMode. It should only be stored if it > differs from ViewMode=1. > > What I noticed is that these global settings are ignored, and (I guess?) > default's Dolphin ones are used instead. For example, if I changed > ~/Pictures/Wallpapers to details view mode. > > $ getfattr -d Pictures/Wallpapers > user.kde.fm. > viewproperties#1="[Dolphin]\012PreviewsShown=false\012Timestamp=2025,2,6,22, > 48,53.577\012Version=4\012ViewMode=1\012" > > Notice that there are two things wrong here: PreviewsShown=false should not > be saved, and ViewMode=1 should not be saved. > > If I enable previews, then > > $ getfattr -d Pictures/Wallpapers > user.kde.fm.viewproperties#1="[Dolphin]\012Timestamp=2025,2,6,22,50,8. > 382\012Version=4\012ViewMode=1\012" > > Again, wrong, because PreviewsShown=true should be saved! > > And what happens when I changed both to Icons view and show previews? Bingo! > > $ getfattr -d Pictures/Wallpapers > (Nothing!) > > When it should, instead, have saved both PreviewsShown=true and the view > mode... > > In the source code, the attributes are deleted because boolean allDefault > (line 534 in current master) gets set to true. > > Hope this helps someone more familiar with Dolphin source code. If I'm not > wrong above (which maybe I am...), I don't understand why is so hard to > reproduce the issue... Well spotted indeed, that's an issue. https://invent.kde.org/system/dolphin/-/blob/master/src/views/viewproperties.cpp#L535 It uses item->isDefault() but this compares to the hardcoded default view settings, not the use defined ones as expected. Something I had overlooked. That would mean dolphin with debug logs would exhibit `clearing extended attributes for` sometimes. But I didn't see it previously. Do you see it when using ? QT_LOGGING_RULES="org.kde.dolphin.debug=true" dolphin I don't want to waste your time though, with the getfattr logs you shared, I can already confirm the issue. Thank you verify much for this research work.
(In reply to Méven from comment #70) > (In reply to Iyán M. V. from comment #68) > > Some thought after reading a bit the source code. I think the issue might > > come from a bug in the logic of when to store settings, and when not. It > > should check if settings in that folder differ from the global ones, not the > > default ones from Dolphin. > > > > These are my global settings, saved by configuring Dolphin to "use common > > display style for all folders", modifying the settings to my like (i.e., > > details view, no previews) and then changing back to "remember display style > > for each folder" > > > > $ getfattr -d ~/.local/share/dolphin/view_properties/global > > # file: home/iyan/.local/share/dolphin/view_properties/global > > user.kde.fm. > > viewproperties#1="[Dolphin]\012PreviewsShown=false\012Timestamp=2025,2,6,22, > > 18,9.49\012Version=4\012ViewMode=1\012" > > > > Since PreviewsShown=false there, I would expect that any directory with > > PreviewsShown=true should store this in the filesystem attributes or in the > > .directory file. Same goes for ViewMode. It should only be stored if it > > differs from ViewMode=1. > > > > What I noticed is that these global settings are ignored, and (I guess?) > > default's Dolphin ones are used instead. For example, if I changed > > ~/Pictures/Wallpapers to details view mode. > > > > $ getfattr -d Pictures/Wallpapers > > user.kde.fm. > > viewproperties#1="[Dolphin]\012PreviewsShown=false\012Timestamp=2025,2,6,22, > > 48,53.577\012Version=4\012ViewMode=1\012" > > > > Notice that there are two things wrong here: PreviewsShown=false should not > > be saved, and ViewMode=1 should not be saved. > > > > If I enable previews, then > > > > $ getfattr -d Pictures/Wallpapers > > user.kde.fm.viewproperties#1="[Dolphin]\012Timestamp=2025,2,6,22,50,8. > > 382\012Version=4\012ViewMode=1\012" > > > > Again, wrong, because PreviewsShown=true should be saved! > > > > And what happens when I changed both to Icons view and show previews? Bingo! > > > > $ getfattr -d Pictures/Wallpapers > > (Nothing!) > > > > When it should, instead, have saved both PreviewsShown=true and the view > > mode... > > > > In the source code, the attributes are deleted because boolean allDefault > > (line 534 in current master) gets set to true. > > > > Hope this helps someone more familiar with Dolphin source code. If I'm not > > wrong above (which maybe I am...), I don't understand why is so hard to > > reproduce the issue... > > Well spotted indeed, that's an issue. > https://invent.kde.org/system/dolphin/-/blob/master/src/views/viewproperties. > cpp#L535 > It uses item->isDefault() but this compares to the hardcoded default view > settings, not the use defined ones as expected. > Something I had overlooked. > > That would mean dolphin with debug logs would exhibit `clearing extended > attributes for` sometimes. > But I didn't see it previously. > Do you see it when using ? > QT_LOGGING_RULES="org.kde.dolphin.debug=true" dolphin > I don't want to waste your time though, with the getfattr logs you shared, I > can already confirm the issue. > Thank you verify much for this research work. So I'm glad that this found the issue but I must point out this proves that the test cases for dolphin for this case are insufficient. Is it only testing with default values? It makes sense why my case and his case are different, since I have nearly default settings, except my view mode is details and not icons by default. I hope the test cases are updated after this. Btw in regards to the debug question you had, no case I've ever tried had the message 'clearing extended attributes for' you mentioned, but also my test cases are limited to the ones I mentioned previously. Thank you guys for working on this annoying bug, I hope it gets patched in soon. I'm glad it's not a major bug at least.
(In reply to Méven from comment #70) > That would mean dolphin with debug logs would exhibit `clearing extended > attributes for` sometimes. > But I didn't see it previously. > Do you see it when using ? > QT_LOGGING_RULES="org.kde.dolphin.debug=true" dolphin > I don't want to waste your time though, with the getfattr logs you shared, I > can already confirm the issue. > Thank you verify much for this research work. That is exactly what happens on my side. $ QT_LOGGING_RULES="org.kde.dolphin.debug=true" ./build/bin/dolphin 127 ↵ org.kde.dolphin: Saving view-properties to "/home/iyan/Pictures/Wallpapers" org.kde.dolphin: Saving view-properties to "/home/iyan/Pictures/Wallpapers" org.kde.dolphin: clearing extended attributes for "/home/iyan/Pictures/Wallpapers"
On thing I can't understand is why the commit from Akseli triggers the bug (which I think it was introduced before). Maybe that I can answer after a second round checking the source code...
A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/905
Git commit c12946ee2ec8dbbb8645ca5763584574458a0a6c by Méven Car. Committed on 08/02/2025 at 08:43. Pushed by meven into branch 'master'. Viewproperties: prevent loosing view settings When they match the hardcoded internal settings, when they should be kept as long as they don't match the currently set default viewproperties. Is saved in metadata the diff with the hardcoded internal defaults still. A stable default reference allows to change defaults without changing existing saved viewproperties. M +64 -0 src/tests/viewpropertiestest.cpp M +21 -3 src/views/viewproperties.cpp https://invent.kde.org/system/dolphin/-/commit/c12946ee2ec8dbbb8645ca5763584574458a0a6c
(In reply to Méven from comment #75) > Git commit c12946ee2ec8dbbb8645ca5763584574458a0a6c by Méven Car. > Committed on 08/02/2025 at 08:43. > Pushed by meven into branch 'master'. > > Viewproperties: prevent loosing view settings > > When they match the hardcoded internal settings, when they should be > kept as long as they don't match the currently set default > viewproperties. > > Is saved in metadata the diff with the hardcoded internal defaults > still. A stable default reference allows to change defaults without > changing existing saved viewproperties. > > M +64 -0 src/tests/viewpropertiestest.cpp > M +21 -3 src/views/viewproperties.cpp > > https://invent.kde.org/system/dolphin/-/commit/ > c12946ee2ec8dbbb8645ca5763584574458a0a6c Iyán M. V. since you were testing with master, can you give master a try again and share the result.
(In reply to Iyán M. V. from comment #73) > On thing I can't understand is why the commit from Akseli triggers the bug > (which I think it was introduced before). Maybe that I can answer after a > second round checking the source code... Before the default settings set by the user was ignored and so the defaults settings were the hardcoded ones matching the condition for item->isDefault in save(). Fixing this bug exposed the next one. This happens commonly in software bug fixing.
(In reply to Méven Car from comment #77) > (In reply to Iyán M. V. from comment #73) > > On thing I can't understand is why the commit from Akseli triggers the bug > > (which I think it was introduced before). Maybe that I can answer after a > > second round checking the source code... > > Before the default settings set by the user was ignored and so the defaults > settings were the hardcoded ones matching the condition for item->isDefault > in save(). > Fixing this bug exposed the next one. > This happens commonly in software bug fixing. Thanks :) (In reply to Méven Car from comment #76) > (In reply to Méven from comment #75) > > Git commit c12946ee2ec8dbbb8645ca5763584574458a0a6c by Méven Car. > > Committed on 08/02/2025 at 08:43. > > Pushed by meven into branch 'master'. > > > > Viewproperties: prevent loosing view settings > > > > When they match the hardcoded internal settings, when they should be > > kept as long as they don't match the currently set default > > viewproperties. > > > > Is saved in metadata the diff with the hardcoded internal defaults > > still. A stable default reference allows to change defaults without > > changing existing saved viewproperties. > > > > M +64 -0 src/tests/viewpropertiestest.cpp > > M +21 -3 src/views/viewproperties.cpp > > > > https://invent.kde.org/system/dolphin/-/commit/ > > c12946ee2ec8dbbb8645ca5763584574458a0a6c > > Iyán M. V. since you were testing with master, can you give master a try > again and share the result. Yes, master works as expected for me now. Attributes are not deleted in the case of Icons + Previews on. Issue is fixed for me. One comment though, maybe this is the intended behavior but I'm not sure. What gets saved to the attributes are still the differences with respect the default Dolphin settings, not the global settings. For example, what I get now, after these last patches is: $ getfattr -d ~/Pictures/Wallpapers 141 ↵ # file: home/iyan/Pictures/Wallpapers user.kde.fm.viewproperties#1="[Dolphin]\012Timestamp=2025,2,8,15,10,9.724\012Version=4\012" I'm fine with this, but just letting you know, in case this is not the desired behavior.
A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/908
Git commit 092916a3113ad55ca74a21b0bf6b1e20c98ed92c by Méven Car. Committed on 09/02/2025 at 10:25. Pushed by meven into branch 'release/24.12'. Viewproperties: prevent loosing view settings When they match the hardcoded internal settings, when they should be kept as long as they don't match the currently set default viewproperties. Is saved in metadata the diff with the hardcoded internal defaults still. A stable default reference allows to change defaults without changing existing saved viewproperties. (cherry picked from commit c12946ee2ec8dbbb8645ca5763584574458a0a6c) M +64 -0 src/tests/viewpropertiestest.cpp M +21 -3 src/views/viewproperties.cpp https://invent.kde.org/system/dolphin/-/commit/092916a3113ad55ca74a21b0bf6b1e20c98ed92c
> I'm fine with this, but just letting you know, in case this is not the desired behavior. That's expected, the defaults with data on disk are just a way to save space and the format must not change or view properties will change for folders with user view properties set, depending on the new defaults the user has selected, that would feel unexpected. I have backported the fix to 24.12 branch so the next bug fix release will ship with it 24.12.3. https://invent.kde.org/system/dolphin/-/commit/092916a3113ad55ca74a21b0bf6b1e20c98ed92c BananasGoMoo whenever you update to Dolphin 24.12.3, if you can't confirm the bug is fixed for you, please open a NEW bug then with a reference to this one.