Tim: > > In either case, once you put any drive in a case (pun intended), you > > are reliant on that enclosure supporting SMART. Some USB enclosures do > > not, they are a barrier to direct access to the drive needed for SMART > > interrogation.
home user: > Thank-you, Tim. > Is the last paragraph above a major reason S.M.A.R.T cannot check USB > sticks? I wouldn't say so in so many words... A storage device has to have the code in its firmware to support SMART. And if there's an interface between it and the computer, that interface has to support SMART, too (or, at least, not break the functionality needed for it to work). So, cheap enclosures, built for minimal effort, are not likely to support it. Likewise, cheap storage devices. If I were playing the devil's advocate, I might say that USB sticks don't implement SMART not just for the sake of can't be bothered to, but probably the multitude of error results would horrify the end user. Lots of drive types silently handle errors without the user ever knowing, some have reserve extra space than the drive's advertised size, for it to work through as the failure rates accumulate. > The f3 suite can check capacity only, but not non-destructively - > useless once something has been written to the stick that I don't want > to lose. > Is there a way to check a stick non-destructively? All I can think of is checksumming the files on it. Though I have to say that the more you use a USB flash drive, the more it wears out. Writing is **more** wearing, but reading is wearing, too. Like I said early, I wouldn't use them for back-ups. I consider them a sneakernet device. And they're not that robust at that, either. How badly do I think of memory storage devices? I have cameras and recorders that use SD cards (often considered better than USB memory sticks). I don't re-use the cards. I use them until they're not quite completely full, copying files off them to my editing system as I go along, then stick the SD cards in a box. They're a failsafe for getting a file back again if I lose it. But I don't trust them to erase and reuse them. In fact, reformatting them is a good way to make them unusable in some devices. > > My real email is brought into a local IMAP server (Dovecot), and my > > local email program is Evolution. *I* wouldn't bother trying to backup > > Evolution's files, I consider it would be too much of a black art to > > try and restore them. Dovecot, on the other hand, has a far more > > coherent use of files for what it does. > I use imap, messages are not stored locally. > I check for and delete messages I'm really done with, empty the trash > folder, empty the spam folder, clear out filter logs, exit Thunderbird, > log off, log back in, and proceed with back-up. I use the Lightning > calendar packaged with Thunderbird, but it's not on-line. I need it > backed-up. I suspect there are probably things designed for backing up Thunderbird files. I know you can do that sort of thing within email programs, but that tends to be aimed at how to keep your mail when you install a new OS or move to another computer. And it'd be very inconvenient to go through a plethora of things to back up your computer on an ongoing basis. I think it would hard for a general-purpose backup program to backup the parts of Thunderbird that someone might require, but ignore other aspects, and do it in a way that Thunderbird could actually make use of the backed up files in a restoration. There's things like the messages, the indexes of the messages, the program configuration about the message storage... I suspect it'd have to backup everything, to make it less painful to try and restore lost content. That's the other aspect of back-ups. You have to be able to restore from them, and you should really test that you can. -- uname -rsvp Linux 3.10.0-1160.119.1.el7.x86_64 #1 SMP Tue Jun 4 14:43:51 UTC 2024 x86_64 (yes, this is the output from uname for this PC when I posted) Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list. -- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
