On 7/7/23 08:25, Max Nikulin wrote:
On 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=256
Looks 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 by
nsenter --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)?
It appears that digiKam, in its weekly builds of the upcoming
digKam-8.1.0, has solved the problem. What specifically was changed IDK
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/>
