I am happy to hear that you are looking at this.
I did create at least one 32GB filesystem but it was too large even
compressed - but suitable for uploading.
Now that buster is obsoleted, and bookworm does not exhibit the errors
(rather, its operations appear to avoid the errors with workarounds -
each of which slows copying, but one cannot ask for more) I will verify
that on Bullseye first.
Ben Hutchings wrote:
On Wed, 2024-08-07 at 00:07 -0400, Bud Heal wrote:
Ben Hutchings wrote:
On Tue, 2024-06-04 at 06:51 -0400, Bud Heal wrote:
I filled up the (micro)SDs, including the current one I have been scanning
into, the one that I set aside as probably defective and the pair I bought
for testing. I will append the bash script.
I appreciate that you've scripted this, but you missed step 2: remove
and reinsert the card. Without that, the script may just be reading
files out of the cache if your system has enough RAM.
Do I read this clearly enough - that you have not tried this either? I
gave bug reports mentioning three devices - a scanner saving to a
microSD, a builtin SD read/writer, and transfer to Windows 10 to
confirmation and comparison, innumerable times.
But no-one else has reported similar issues, and I don't have the same
devices, which is why I kept asking you to run tests.
I have now tried reproducing this with my own microSD card and reader,
and didn't see this problem.
Simply removing and reinserting the microSC card can lead to
irrecoverable corruption requiring a reformat. At best it will lead to
loss of the last set of scans, prior to inserting the card into the
Debian system.
[...]
So one or both of:
- A change in the way this newer version of GNOME (or whichever desktop
environment you're using) does thumbnail generation
- Using USB storage instead of an SD controller
mitigates the problem, but we don't know which.
Using USB storage does not mitigate the problem. You have a bug
corrupting a file system and losing data for an unwary user.
I was not suggesting that this was a practical mitigation. I am trying
to understand what the exact conditions are for this issue to occur.
There may
be a patch ready to be backported in the latest version, but that is not
mine to know. I have given you all that is needed to replicate the
problem. Fill a device full enough to let you open a folder while it is
generating thumbnails, and test, or not.
But I couldn't replicate the problem.
At this point I think it would be helpful to get disk images of a card
that shows this issue:
1. Erase a card completely, to avoid private data being included in the
images.
2. Use the scanner to format and add some non-sensitive images to the
card.
3. Insert the card into a Linux system with automounting disabled (i.e.
no desktop running).
4. Use dd and gzip to create an image of the card before corruption.
5. Start the desktop and verify that the card does gets corrupted from
the state that was imaged. If not, go back to step 2.
6. Use dd and gzip to create an image of the card with corruption.
I'm guessing the disk images are going to be rather large, in which
case they should not be attached to this bug report. I can send you a
link privately to upload them.
Ben.
