Howdy,
As some may recall, I have quite a few deer trail cameras that use SD
memory cards. On occasion some of the cards start acting weird. I've
got one that is really weird. Usually I just replace them but this one
is a bit of a puzzle I'd like to solve. When it stopped working, it had
a dozen or so short videos on it that are about 30MBs on average. Some
color and large, some black and white night vision and fairly small.
When it stopped working, I tried to reformat the thing. The files
remained even after that. I then ran dd and zeroed the thing, files
still there even tho dd reported no problems. I then used this GUI disk program that tests memory cards and it claims the card is fine. It
writes files to it, reads them back. I also used it to reformat the
card. The original videos are still there. Today I decided to play
with it again. I ran this dd command on the stick.
root@fireball / # dd if=/dev/zero of=/dev/sdh bs=4K conv=notrunc
oflag=direct status=progress
31907364864 bytes (32 GB, 30 GiB) copied, 3956 s, 8.1 MB/s
dd: error writing '/dev/sdh': No space left on device
7791745+0 records in
7791744+0 records out
31914983424 bytes (32 GB, 30 GiB) copied, 3956.94 s, 8.1 MB/s
root@fireball / #
As you can see, no errors. It wrote zeros until it ran out of space.
Guess what, the original videos are still on the card. File listing:
root@fireball / # ls -al /run/media/dale/2140-2E00/DCIM/100MEDIA/*
-rw-r--r-- 1 dale users 0 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/AAAAAAAA.AAA
-rw-r--r-- 1 dale users 0 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/BBBBBBBB.BBB
-rw-r--r-- 1 dale users 14335272 May 2 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0823.AVI
-rw-r--r-- 1 dale users 50843576 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0824.AVI
-rw-r--r-- 1 dale users 53137560 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0825.AVI
-rw-r--r-- 1 dale users 18398504 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0826.AVI
-rw-r--r-- 1 dale users 18922808 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0827.AVI
-rw-r--r-- 1 dale users 18332888 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0828.AVI
-rw-r--r-- 1 dale users 18726200 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0829.AVI
-rw-r--r-- 1 dale users 18332920 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0830.AVI
-rw-r--r-- 1 dale users 18005288 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0831.AVI
-rw-r--r-- 1 dale users 17612088 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0832.AVI
-rw-r--r-- 1 dale users 17153336 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0833.AVI
-rw-r--r-- 1 dale users 16694584 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0834.AVI
-rw-r--r-- 1 dale users 0 May 6 2018 /run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0835.AVI
root@fireball / #
The zero byte files are broken, my first clue way back that the card
needed replacing. I see no errors in dmesg or messages. Usually the
cards produce errors and it remounts read only. Not in this case tho.
Mount info:
root@fireball / # mount | grep sdh
/dev/sdh1 on /run/media/dale/2140-2E00 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0022,codepage=43 7,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro, uhelper=udisks2) root@fireball / #
In the past, I've at times been able to copy the files off other cards
going bad but it stays read only. Reformating fails etc etc.
Sometimes, it just plain doesn't work. Almost always tho I get a error
of some kind in messages or dmesg if not both. This one tho, it's just
plain weird. No errors but nothing removes the files either. Oh, I've checked the lock button. It's not locked. It is shown that way in
dmesg as well.
[2592841.808336] sd 10:0:0:2: [sdh] Write Protect is off
Obviously I'm not going to trust this thing. It will end up in the
trash but, does this make sense to anyone else? Of all the ones I've
worn out, this is the only one that behaves this way. I'd at least
expect the format to fail or it only mount read only. At least some
sort of error anyway.
Thoughts?
Dale
:-) :-)
On Tuesday, 28 December 2021 20:21:32 GMT Dale wrote:
Howdy,I don't think I've come across something like this before. In my case data is
As some may recall, I have quite a few deer trail cameras that use SD
memory cards. On occasion some of the cards start acting weird. I've
got one that is really weird. Usually I just replace them but this one
is a bit of a puzzle I'd like to solve. When it stopped working, it had
a dozen or so short videos on it that are about 30MBs on average. Some
color and large, some black and white night vision and fairly small.
When it stopped working, I tried to reformat the thing. The files
remained even after that. I then ran dd and zeroed the thing, files
still there even tho dd reported no problems. I then used this GUI disk
program that tests memory cards and it claims the card is fine. It
writes files to it, reads them back. I also used it to reformat the
card. The original videos are still there. Today I decided to play
with it again. I ran this dd command on the stick.
root@fireball / # dd if=/dev/zero of=/dev/sdh bs=4K conv=notrunc
oflag=direct status=progress
31907364864 bytes (32 GB, 30 GiB) copied, 3956 s, 8.1 MB/s
dd: error writing '/dev/sdh': No space left on device
7791745+0 records in
7791744+0 records out
31914983424 bytes (32 GB, 30 GiB) copied, 3956.94 s, 8.1 MB/s
root@fireball / #
As you can see, no errors. It wrote zeros until it ran out of space.
Guess what, the original videos are still on the card. File listing:
root@fireball / # ls -al /run/media/dale/2140-2E00/DCIM/100MEDIA/*
-rw-r--r-- 1 dale users 0 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/AAAAAAAA.AAA
-rw-r--r-- 1 dale users 0 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/BBBBBBBB.BBB
-rw-r--r-- 1 dale users 14335272 May 2 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0823.AVI
-rw-r--r-- 1 dale users 50843576 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0824.AVI
-rw-r--r-- 1 dale users 53137560 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0825.AVI
-rw-r--r-- 1 dale users 18398504 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0826.AVI
-rw-r--r-- 1 dale users 18922808 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0827.AVI
-rw-r--r-- 1 dale users 18332888 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0828.AVI
-rw-r--r-- 1 dale users 18726200 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0829.AVI
-rw-r--r-- 1 dale users 18332920 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0830.AVI
-rw-r--r-- 1 dale users 18005288 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0831.AVI
-rw-r--r-- 1 dale users 17612088 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0832.AVI
-rw-r--r-- 1 dale users 17153336 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0833.AVI
-rw-r--r-- 1 dale users 16694584 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0834.AVI
-rw-r--r-- 1 dale users 0 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0835.AVI
root@fireball / #
The zero byte files are broken, my first clue way back that the card
needed replacing. I see no errors in dmesg or messages. Usually the
cards produce errors and it remounts read only. Not in this case tho.
Mount info:
root@fireball / # mount | grep sdh
/dev/sdh1 on /run/media/dale/2140-2E00 type vfat
(rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0022,codepage=43 >> 7,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro, >> uhelper=udisks2) root@fireball / #
In the past, I've at times been able to copy the files off other cards
going bad but it stays read only. Reformating fails etc etc.
Sometimes, it just plain doesn't work. Almost always tho I get a error
of some kind in messages or dmesg if not both. This one tho, it's just
plain weird. No errors but nothing removes the files either. Oh, I've
checked the lock button. It's not locked. It is shown that way in
dmesg as well.
[2592841.808336] sd 10:0:0:2: [sdh] Write Protect is off
Obviously I'm not going to trust this thing. It will end up in the
trash but, does this make sense to anyone else? Of all the ones I've
worn out, this is the only one that behaves this way. I'd at least
expect the format to fail or it only mount read only. At least some
sort of error anyway.
Thoughts?
Dale
:-) :-)
lost, occasionally irretrievably.
I suppose something has switched blocks on the SD as immutable, probably a controller having a hiccup.
You could try blkdiscard to erase blocks directly - but I haven't tried this on an SD. I also haven't tried to know if it will work at all hdparm's secure
deletion.
However, the best option is to see if the OEM offers a reset app for this particular card and use that.
So while rare, it's not just me. ;-) I've had cards fail by just plain refusing not to mount at all, mounting read only and such. I've never
had one to fail like this tho. I guess if this was some sort of
sensitive files, I'd have to put it in a shredder or take a pair of
scissors to it. LOL
I ordered 6 new cards as replacements. They came in yesterday. Like I
said, I wouldn't trust that card even if it started working again. So,
off to the trash the weird card goes. Now I just have to wonder why dd
and such didn't report problems. :/
Thanks to all for the info. Interesting.
Dale
:-) :-)
On 29/12/21 20:26, Michael wrote:
On Tuesday, 28 December 2021 20:21:32 GMT Dale wrote:
Howdy,I don't think I've come across something like this before. In my
As some may recall, I have quite a few deer trail cameras that use SD
memory cards. On occasion some of the cards start acting weird. I've >>> got one that is really weird. Usually I just replace them but this one >>> is a bit of a puzzle I'd like to solve. When it stopped working, it
had
a dozen or so short videos on it that are about 30MBs on average. Some >>> color and large, some black and white night vision and fairly small.
When it stopped working, I tried to reformat the thing. The files
remained even after that. I then ran dd and zeroed the thing, files
still there even tho dd reported no problems. I then used this GUI
disk
program that tests memory cards and it claims the card is fine. It
writes files to it, reads them back. I also used it to reformat the
card. The original videos are still there. Today I decided to play
with it again. I ran this dd command on the stick.
root@fireball / # dd if=/dev/zero of=/dev/sdh bs=4K conv=notrunc
oflag=direct status=progress
31907364864 bytes (32 GB, 30 GiB) copied, 3956 s, 8.1 MB/s
dd: error writing '/dev/sdh': No space left on device
7791745+0 records in
7791744+0 records out
31914983424 bytes (32 GB, 30 GiB) copied, 3956.94 s, 8.1 MB/s
root@fireball / #
As you can see, no errors. It wrote zeros until it ran out of space.
Guess what, the original videos are still on the card. File listing:
root@fireball / # ls -al /run/media/dale/2140-2E00/DCIM/100MEDIA/*
-rw-r--r-- 1 dale users 0 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/AAAAAAAA.AAA
-rw-r--r-- 1 dale users 0 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/BBBBBBBB.BBB
-rw-r--r-- 1 dale users 14335272 May 2 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0823.AVI
-rw-r--r-- 1 dale users 50843576 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0824.AVI
-rw-r--r-- 1 dale users 53137560 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0825.AVI
-rw-r--r-- 1 dale users 18398504 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0826.AVI
-rw-r--r-- 1 dale users 18922808 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0827.AVI
-rw-r--r-- 1 dale users 18332888 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0828.AVI
-rw-r--r-- 1 dale users 18726200 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0829.AVI
-rw-r--r-- 1 dale users 18332920 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0830.AVI
-rw-r--r-- 1 dale users 18005288 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0831.AVI
-rw-r--r-- 1 dale users 17612088 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0832.AVI
-rw-r--r-- 1 dale users 17153336 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0833.AVI
-rw-r--r-- 1 dale users 16694584 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0834.AVI
-rw-r--r-- 1 dale users 0 May 6 2018
/run/media/dale/2140-2E00/DCIM/100MEDIA/WGI_0835.AVI
root@fireball / #
The zero byte files are broken, my first clue way back that the card
needed replacing. I see no errors in dmesg or messages. Usually the
cards produce errors and it remounts read only. Not in this case tho.
Mount info:
root@fireball / # mount | grep sdh
/dev/sdh1 on /run/media/dale/2140-2E00 type vfat
(rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0022,codepage=43
7,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,
uhelper=udisks2) root@fireball / #
In the past, I've at times been able to copy the files off other cards
going bad but it stays read only. Reformating fails etc etc.
Sometimes, it just plain doesn't work. Almost always tho I get a error >>> of some kind in messages or dmesg if not both. This one tho, it's just >>> plain weird. No errors but nothing removes the files either. Oh, I've >>> checked the lock button. It's not locked. It is shown that way in
dmesg as well.
[2592841.808336] sd 10:0:0:2: [sdh] Write Protect is off
Obviously I'm not going to trust this thing. It will end up in the
trash but, does this make sense to anyone else? Of all the ones I've
worn out, this is the only one that behaves this way. I'd at least
expect the format to fail or it only mount read only. At least some
sort of error anyway.
Thoughts?
Dale
:-) :-)
case data is
lost, occasionally irretrievably.
I suppose something has switched blocks on the SD as immutable,
probably a
controller having a hiccup.
You could try blkdiscard to erase blocks directly - but I haven't
tried this
on an SD. I also haven't tried to know if it will work at all
hdparm's secure
deletion.
However, the best option is to see if the OEM offers a reset app for
this
particular card and use that.
I have a few SD cards as OS disks on raspberry pi, odroids etc. One
has your symptoms like yours - read only when it says its in write
mode. Took two days after the last write to syslog to drop dead -
just before Christmas too, luckily it was part of a moosefs cluster so
I could leave it in maintenance mode without affecting service -
replaced today. No salvaging it unfortunately - also not the first
one that I have had die like this. I tested some others and have one
thats really slow when dd'ing zeros to clear vacant space (I think
that's redundant for SD cards, better to trim it?) before making a compressable backup image. It also drops to RO with no errors in
syslog before completing. So I am down 2 cards and need to order some
more spares before another fails :(
BillK
<SNIP>
Actually, it's possible that it failed this way by design. What if the
So while rare, it's not just me. ;-) I've had cards fail by just plain
refusing not to mount at all, mounting read only and such. I've never
had one to fail like this tho. I guess if this was some sort of
sensitive files, I'd have to put it in a shredder or take a pair of
scissors to it. LOL
I ordered 6 new cards as replacements. They came in yesterday. Like I
said, I wouldn't trust that card even if it started working again. So,
off to the trash the weird card goes. Now I just have to wonder why dd
and such didn't report problems. :/
Thanks to all for the info. Interesting.
Dale
:-) :-)
card recognized that it's in some sort of a wear out condition and
just shut off new writes? One might see it as a failure but a
different view is as a potential opportunity to retrieve data before
it's gone.
You might want to check out this tool:
https://github.com/BertoldVdb/sdtool
which advertises that it can view, set and reset the write protection
status of an SD card. Can't hurt if you're committed to throwing the
device in the trash can anyway. (Well, it could possibly hose your
system if you use it incorrectly or if it has bugs, but that's true
about all software, right?) ;-)
But at least you could view the status of the card.
Cheers,
Mark
Mark Knecht wrote:
<SNIP>
Actually, it's possible that it failed this way by design. What if the
So while rare, it's not just me. ;-) I've had cards fail by just plain >> refusing not to mount at all, mounting read only and such. I've never
had one to fail like this tho. I guess if this was some sort of
sensitive files, I'd have to put it in a shredder or take a pair of
scissors to it. LOL
I ordered 6 new cards as replacements. They came in yesterday. Like I
said, I wouldn't trust that card even if it started working again. So,
off to the trash the weird card goes. Now I just have to wonder why dd
and such didn't report problems. :/
Thanks to all for the info. Interesting.
Dale
:-) :-)
card recognized that it's in some sort of a wear out condition and
just shut off new writes? One might see it as a failure but a
different view is as a potential opportunity to retrieve data before
it's gone.
You might want to check out this tool:
https://github.com/BertoldVdb/sdtool
which advertises that it can view, set and reset the write protection status of an SD card. Can't hurt if you're committed to throwing the
device in the trash can anyway. (Well, it could possibly hose your
system if you use it incorrectly or if it has bugs, but that's true
about all software, right?) ;-)
But at least you could view the status of the card.
Cheers,
Mark
I downloaded sdtool but I don't have the required devices in /dev to use
it. In the readme it says not to use /dev/sd* but to use /dev/mmcblk*.
It seems my card reader doesn't connect in a way for those to be
created. Would have been nice just to see what it does tho. I still wouldn't trust it of course but being curious . . . .
By the way, the card is a Sandisk which has a fairly good reputation.
It is possible that it failed in the best way it could. On the positive side, it did fail in a way that the files could be recovered. That's
always a good thing. It's certainly better than failing with no way to
get the files.
Dale
On Wed, Dec 29, 2021 at 10:14 AM Dale <rdalek1967@gmail.com> wrote:
Mark Knecht wrote:OK, sorry it's not easy. I suppose now that you are using some sort of
<SNIP>
So while rare, it's not just me. ;-) I've had cards fail by just plain >>>> refusing not to mount at all, mounting read only and such. I've never >>>> had one to fail like this tho. I guess if this was some sort ofActually, it's possible that it failed this way by design. What if the
sensitive files, I'd have to put it in a shredder or take a pair of
scissors to it. LOL
I ordered 6 new cards as replacements. They came in yesterday. Like I >>>> said, I wouldn't trust that card even if it started working again. So, >>>> off to the trash the weird card goes. Now I just have to wonder why dd >>>> and such didn't report problems. :/
Thanks to all for the info. Interesting.
Dale
:-) :-)
card recognized that it's in some sort of a wear out condition and
just shut off new writes? One might see it as a failure but a
different view is as a potential opportunity to retrieve data before
it's gone.
You might want to check out this tool:
https://github.com/BertoldVdb/sdtool
which advertises that it can view, set and reset the write protection
status of an SD card. Can't hurt if you're committed to throwing the
device in the trash can anyway. (Well, it could possibly hose your
system if you use it incorrectly or if it has bugs, but that's true
about all software, right?) ;-)
But at least you could view the status of the card.
Cheers,
Mark
I downloaded sdtool but I don't have the required devices in /dev to use
it. In the readme it says not to use /dev/sd* but to use /dev/mmcblk*.
It seems my card reader doesn't connect in a way for those to be
created. Would have been nice just to see what it does tho. I still
wouldn't trust it of course but being curious . . . .
By the way, the card is a Sandisk which has a fairly good reputation.
It is possible that it failed in the best way it could. On the positive
side, it did fail in a way that the files could be recovered. That's
always a good thing. It's certainly better than failing with no way to
get the files.
Dale
USB bridge for reading your SD cards? That probably makes it show up
as a standard /dev/sd device like other USB drives.
I may be wrong, and it might not help you, but I think /dev/mmc is
enabled through the MMC_BLOCK option in the kernel, but even if you
enable that it may not change things if you have a USB bridge in the
way.
On Windows there are some partition editors that show the state of
these bits. I haven't looked for a standard Linux partition editor
that does that but it's probably out there somewhere if you go
hunting.
If you own a DSLR that supports whatever size SD card you are using
then it probably has a way to write protect cards while in the camera. However if it's just a web cam that you're using it probably doesn't
but check the documentation.
Good luck,
Mark
Mark Knecht wrote:
On Wed, Dec 29, 2021 at 10:14 AM Dale <rdalek1967@gmail.com> wrote:
Mark Knecht wrote:OK, sorry it's not easy. I suppose now that you are using some sort of
<SNIP>
So while rare, it's not just me. ;-) I've had cards fail by just plain >>>> refusing not to mount at all, mounting read only and such. I've never >>>> had one to fail like this tho. I guess if this was some sort ofActually, it's possible that it failed this way by design. What if the >>> card recognized that it's in some sort of a wear out condition and
sensitive files, I'd have to put it in a shredder or take a pair of
scissors to it. LOL
I ordered 6 new cards as replacements. They came in yesterday. Like I >>>> said, I wouldn't trust that card even if it started working again. So, >>>> off to the trash the weird card goes. Now I just have to wonder why dd >>>> and such didn't report problems. :/
Thanks to all for the info. Interesting.
Dale
:-) :-)
just shut off new writes? One might see it as a failure but a
different view is as a potential opportunity to retrieve data before
it's gone.
You might want to check out this tool:
https://github.com/BertoldVdb/sdtool
which advertises that it can view, set and reset the write protection
status of an SD card. Can't hurt if you're committed to throwing the
device in the trash can anyway. (Well, it could possibly hose your
system if you use it incorrectly or if it has bugs, but that's true
about all software, right?) ;-)
But at least you could view the status of the card.
Cheers,
Mark
I downloaded sdtool but I don't have the required devices in /dev to use >> it. In the readme it says not to use /dev/sd* but to use /dev/mmcblk*.
It seems my card reader doesn't connect in a way for those to be
created. Would have been nice just to see what it does tho. I still
wouldn't trust it of course but being curious . . . .
By the way, the card is a Sandisk which has a fairly good reputation.
It is possible that it failed in the best way it could. On the positive >> side, it did fail in a way that the files could be recovered. That's
always a good thing. It's certainly better than failing with no way to
get the files.
Dale
USB bridge for reading your SD cards? That probably makes it show up
as a standard /dev/sd device like other USB drives.
I may be wrong, and it might not help you, but I think /dev/mmc is
enabled through the MMC_BLOCK option in the kernel, but even if you
enable that it may not change things if you have a USB bridge in the
way.
On Windows there are some partition editors that show the state of
these bits. I haven't looked for a standard Linux partition editor
that does that but it's probably out there somewhere if you go
hunting.
If you own a DSLR that supports whatever size SD card you are using
then it probably has a way to write protect cards while in the camera. However if it's just a web cam that you're using it probably doesn't
but check the documentation.
Good luck,
Mark
Those deer trail cameras are somewhat cheap, ish. Some of them don't
even have a format option. I have a old camera that the IR sensor
doesn't work on, it never knows something is there to take pictures of
so it does nothing. Anyway, I use it to format cards with since most
all trail cameras use the same format type and directory tree. One
partition and vfat. Basically, it is really simple and not a lot of
options.
I use a card reader that hooks up via USB. It's one of those multi
reader thingys. It's been a pretty good one but it isn't a real
expensive one either. Given I got the data off and plan to trash it
anyway, it's not worth recompiling a kernel, rebooting and then hoping
it will have the right device thingys.
This thread has been interesting tho. At least I know that a Sandisk
card at least tries to fail in a way that I can get the data off that
did get written to the card. Hey, that's a lot better than some I
guess. :-D I've had some other brands that when they die, they dead.
You get nothing at all.
Dale
:-) :-)
This thread has been interesting tho. At least I know that a Sandisk
card at least tries to fail in a way that I can get the data off that
did get written to the card. Hey, that's a lot better than some I
guess. :-D I've had some other brands that when they die, they dead.
You get nothing at all.
Dale
:-) :-)
...
This thread has been interesting tho. At least I know that a SandiskFrom memory (I found some articles describing what was happening when investigating a while back) - its common with other brands too so
card at least tries to fail in a way that I can get the data off that
did get written to the card. Hey, that's a lot better than some I
guess. :-D I've had some other brands that when they die, they dead.
You get nothing at all.
Dale
:-) :-)
might be part of the specification - if it detects a failure, it
forces permanent read only mode to enable data recovery. Some cards
may be put back into write mode by software but not all and I wouldn't
trust it anyway. I have Kingston, Samsung and Sandisk cards - I
regard Samsung as very slightly better but not enough to go out of my
way and pay more for them.
BillK
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 79:49:47 |
| Calls: | 6,658 |
| Calls today: | 4 |
| Files: | 12,203 |
| Messages: | 5,333,178 |
| Posted today: | 1 |