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.
--
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy others.
signature.asc
Description: This is a digitally signed message part
