Mailinglist Archive: opensuse (818 mails)

< Previous Next >
Re: [opensuse] Re: Howto repair - corrupt jpeg file - anything new out there?
On 9/20/2011 10:10 PM, Philipp Thomas wrote:
On Tue, 20 Sep 2011 19:51:10 -0400, "Brian K. White"<brian@xxxxxxxxx>

Wrong again. True only in theory.

How can my experience be wrong? And that isn't theory! All SD cards I
bought, both normal and micro, where factory formatted and
reformatting them and my CF cards under both Linux and Windows didn't
give *any* problems. So please give real examples instead of just
stating the above.


In my experience, Chinese people never die. I mean, I've never seen it happen once.

Why should I do a lot of work exhaustively documenting your ignorance? Feel free to read up on FAT, or don't. I don't care how educated any one person is (IE you), but I do care that false info is stated and goes uncontested, which is a form of assent.

Yes in theory any FAT implimentation that adheres to the spec (oh, wait, what "the" spec, there are multiple specs? gee...) should always work in perfect harmony with any other FAT implementation that also adheres to the same spec, you know, as long as it's a good spec to begin with.

That theory applies, and fails, in practically every thing any human has ever done. There is nothing special about FAT that makes it exempt such that it requires an actual dead baby in your lap to prove that it can fail some times.

But gee if you haven't used enough flash devices to have encountered a few oddball compatibility quirks directly over the years, just do something incredibly advanced like pull up the wikipedia entry for FAT, and right there alone, just as a starter, you should see that between the various versions of fat that exist or have existed, and the various configurable values and the various subsets of those that were actually ever common or ever generated by any Microsoft program, there are many many possible permutations that would all fall within the rules. Any of those might not be liked by some poorly written firmware that only bothered to account for the common case.

Also, this discussion isn't even limited to FAT. The real question was "format on my pc or let the camera do it" well "format on my pc" could just as easily generate NTFS or something else unless you specifically see to it.

My most resent actual issue happened to be with a camera that couldn't handle cards over 2G total size. Except it could, sorta. The docs for the camera simply said 2G of course since that's the biggest size where everything "just works". But if the card is larger, up to 4G but so long as it wasn't an SDHC card, The camera could actually use up to 2G of space just fine, _as long as there was only 2G or less free space on the card_. So, fill up the card with pics or tunes or a movie, using your pc, get the available space down to 2G or less, and then the camera could both take pics and videos normally, but it could even play the movie/tunes/pictures from anywhere in the whole 4G too.

but FAT is FAT is FAT right?

...and we haven't even touched on partitioning. Whenever something is common, such as say, how practically all thumb drives are shipped preformatted with a MSDOS partition table and a single fdisk partition #1 that takes up the whole space, pretty soon countless devices and software grows to make broken assumptions that that which is common is actually the only thing that even exists or is possible. I have no idea what that camera or indeed any camera would do if you partitioned an sd card into more than one partition. probably it would just ignore everything but partition 1, or it might simply say the card is invalid and reject it entirely.

There are no end of boneheaded things that firmware writers do.
Like how some motherboard bios's will not even _try_ to boot a device or partition unless it sees what IT thinks is a standard DOS MBR, even if the partitioning is normal, and there partition is flagged bootable, and there is a valid bootloader there that just doesn't happen to be one of the standard DOS MBR's, it skips it. Or others that make utterly arbitrary decisions based on the size of the device. USB drive smaller than 128M then assume it's a floppy and reject it if it's not FAT12 with a fat12 mbr... and such things that are supposed to work in theory, but don't in reality, are endless.

If you want tosay "in my experience" well that's fine but stress that part a bit more and do not make any actual claims or statements that extend beyond that.

Even within the limited scope of just fat16 and fat32, there are gobs of variables there, and, despite your incredulity, firmware writers and hardware manufacturers really do code for the common case many times and it's altogether easy to be within spec yet outside that devices expectations, just by having an unusual block size or total size or volume name or permissions or partitioning or boot record etc...

Suppose the user unwittingly had their sd slot configured for performance instead of safety (write caching), suppose they had compression turned on? Suppose they had an uncommon locale/codepage? I had one camera that would crash simply if an unexpected file were on the sd card at all. Sure a smart firmware writer would not attempt to scan any files that the camera itself didn't write. In _theory_ that should never have been a problem... Another one choked on jpeg images that were valid but merely had different specs than the few types the camera itself ever produced.

Yes, _usually_ it's not a problem. By definition it can't really be exactly a common problem because any camera that is too delicate about the formatting either quickly becomes an extinct camera or quickly gets fixed with an update.

But usually is only usually.

To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups