On 7/7/23 08:25, Max Nikulin wrote:
It appears that digiKam, in its weekly builds of the upcoming digKam-8.1.0, has solved the problem. What specifically was changed IDKOn 06/07/2023 18:57, gene heskett wrote:gene@coyote:~$ findmnt --target /home/gene/Pictures/Saw4Bruce (didn't work)TARGET SOURCE FSTYPE OPTIONS /home /dev/md0p1 ext4 rw,relatime,errors=remount-ro,stripe=256 gene@coyote:~$ findmnt --target /home/gene/Pictures/Newjuly5dlds (worked) TARGET SOURCE FSTYPE OPTIONS /home /dev/md0p1 ext4 rw,relatime,errors=remount-ro,stripe=256Looks like a purely application issue unrelated to udev, camera, etc.Can you add more photos to Newjuly5dlds? To factor out camera completely, can you copy images withing digikam to these directories? Have you inspected folder (album?) properties as it represented by digikam? Are these directories contain files that are not images and that may contain metadata declaring that some directory should be "protected from writing"? Does digikam use akonadi? Does it connect to the session-wide instance or it runs another one in container? Maybe the application believes that some directories are managed by another application and tries to protect you from a conflict.If you believe that the issue is at a lower level and your way to run digikam really uses namespaces, you may try to inspect its environment bynsenter --all -t PID_OF_DIGIKAM e.g. output of "mount". However it is better to compare at first that ls -l /proc/$$/ns ls -l /proc/PID_OF_DIGIKAM/ns do not identical A sledgehammer for obscure issues is attaching to a process by strace. After all, have you checked ~/.xseession-errors (if it is still in use)?
What caused all this hoohaw, was an apt upgrade of my bullseye install which indicated I should reboot, which I initiated, but when it got to to login, my password wasn't good, it just looped back to the login. and I then tried a single reboot, and again it was denied bad passwd or something.
I had already dl'd the net-install for bookworm and put it on a DVD. So I crawled under the desk and unplugged all the usb's but the keyboard and mouse buttons, and unplugged the sata cables to all drives but the one I intended to install bookworm on, and installed bookworm. Rebooted, worked for the early checks, so I crawled under the desk and hook everything up, editing /etc/fstab to add my raid10 of 4 2T Samsung SSD's as /home, over the nearly empty /home on the installed disk, another 1T Samsung SSD. About 4 or 5 days later I'm staring at a df report, and discovered I was actually booted from /dev/sdb!! So I installed gparted, and canceled the boot flag on the drive I was booted from, and made sure it was set on the bookworm install on /dev.sda. Rebooted, reboot showed I was now on the bookworm drive. Fixed its /etc/fstab to add the raid10 /home. Rebooted again, and here I am with a whole new class of stuff that doesn't work for untraceable reasons as I had zero chance to read the Change Logs, and now no damned logs to read. What the h--- am I supposed to do? hence this discussion. That's all, something has changed how the keyboard buffer is handled, so now, when I'm working in OpenSCAD which I run in 3 workspaces when designing something to print, I must pause between keystrokes and wait for everything in the bottom bar to update, else the are you sure requestor's for cura opens completely behind the shell everything in that workspace was launched from, no way to bring it fwd to visibility, so root session of htop to kill the konsole, killing everything it started, doing everything all over again from the gitgo. So in saving a part as a 3mf I wind up wasting 30 seconds waiting on plasma or whatever its called, in the sequence of move to next workspace, clear cura's build plate, then find and load the just saved 3mf, slice it, save it, wait for plasma to draw the toolbar, then click on the save in the toolbar and finally get the whereto requestor that should have popped up without any interference from plasma. And if the next click isn't in that requester, the requester is moved to invisibility behind the konsole and I must kill the konsole and start all over again. If I wait 3 or 4 seconds for the bottom toolbar to be updated, it all Just Works, but the enforced wait for something that was instantaneous in buster & bullseye is very distracting to an 88 yo's thought processes, leading inevitably to mistakes that result in restarting that whole workspace scenario.
Then I move to the third workspace where a copy of mc is first refreshed, then used to copy the sliced file to the printer over my local network.
Eye candy is fine, but eye candy that gets in the way is not welcome. And this gets in the way. Is there a configure option menu to do away with some parts of it? Just lengthening the double click another 200 ms would help, a lot. It is now so short that my ancient fingers have a hard time preventing the third click that is death to that whole workspace.
Thank you Max, take care and stay well. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/>