1 |
On Wed, Dec 29, 2021 at 10:14 AM Dale <rdalek1967@×××××.com> wrote: |
2 |
> |
3 |
> Mark Knecht wrote: |
4 |
> > <SNIP> |
5 |
> >> |
6 |
> >> So while rare, it's not just me. ;-) I've had cards fail by just plain |
7 |
> >> refusing not to mount at all, mounting read only and such. I've never |
8 |
> >> had one to fail like this tho. I guess if this was some sort of |
9 |
> >> sensitive files, I'd have to put it in a shredder or take a pair of |
10 |
> >> scissors to it. LOL |
11 |
> >> |
12 |
> >> I ordered 6 new cards as replacements. They came in yesterday. Like I |
13 |
> >> said, I wouldn't trust that card even if it started working again. So, |
14 |
> >> off to the trash the weird card goes. Now I just have to wonder why dd |
15 |
> >> and such didn't report problems. :/ |
16 |
> >> |
17 |
> >> Thanks to all for the info. Interesting. |
18 |
> >> |
19 |
> >> Dale |
20 |
> >> |
21 |
> >> :-) :-) |
22 |
> >> |
23 |
> > Actually, it's possible that it failed this way by design. What if the |
24 |
> > card recognized that it's in some sort of a wear out condition and |
25 |
> > just shut off new writes? One might see it as a failure but a |
26 |
> > different view is as a potential opportunity to retrieve data before |
27 |
> > it's gone. |
28 |
> > |
29 |
> > You might want to check out this tool: |
30 |
> > |
31 |
> > https://github.com/BertoldVdb/sdtool |
32 |
> > |
33 |
> > which advertises that it can view, set and reset the write protection |
34 |
> > status of an SD card. Can't hurt if you're committed to throwing the |
35 |
> > device in the trash can anyway. (Well, it could possibly hose your |
36 |
> > system if you use it incorrectly or if it has bugs, but that's true |
37 |
> > about all software, right?) ;-) |
38 |
> > |
39 |
> > But at least you could view the status of the card. |
40 |
> > |
41 |
> > Cheers, |
42 |
> > Mark |
43 |
> > |
44 |
> > |
45 |
> |
46 |
> |
47 |
> I downloaded sdtool but I don't have the required devices in /dev to use |
48 |
> it. In the readme it says not to use /dev/sd* but to use /dev/mmcblk*. |
49 |
> It seems my card reader doesn't connect in a way for those to be |
50 |
> created. Would have been nice just to see what it does tho. I still |
51 |
> wouldn't trust it of course but being curious . . . . |
52 |
> |
53 |
> By the way, the card is a Sandisk which has a fairly good reputation. |
54 |
> It is possible that it failed in the best way it could. On the positive |
55 |
> side, it did fail in a way that the files could be recovered. That's |
56 |
> always a good thing. It's certainly better than failing with no way to |
57 |
> get the files. |
58 |
> |
59 |
> Dale |
60 |
|
61 |
OK, sorry it's not easy. I suppose now that you are using some sort of |
62 |
USB bridge for reading your SD cards? That probably makes it show up |
63 |
as a standard /dev/sd device like other USB drives. |
64 |
|
65 |
I may be wrong, and it might not help you, but I think /dev/mmc is |
66 |
enabled through the MMC_BLOCK option in the kernel, but even if you |
67 |
enable that it may not change things if you have a USB bridge in the |
68 |
way. |
69 |
|
70 |
On Windows there are some partition editors that show the state of |
71 |
these bits. I haven't looked for a standard Linux partition editor |
72 |
that does that but it's probably out there somewhere if you go |
73 |
hunting. |
74 |
|
75 |
If you own a DSLR that supports whatever size SD card you are using |
76 |
then it probably has a way to write protect cards while in the camera. |
77 |
However if it's just a web cam that you're using it probably doesn't |
78 |
but check the documentation. |
79 |
|
80 |
Good luck, |
81 |
Mark |