My code is writting data to a CompactFlash card. I can see the data with WinHex. But, windows does not acknowledge the file. I'm using the same functions as examples that work elsewhere in the project. I need help analyzing the FAT info to see where the problem is so I know where the problem lies in the code. I have read the FAT specs and compared my file to good files and the differences are just not evident. Any help on this would be most appreciated. I'm really under the gun here. Sean W.
FAT16 help needed!!!
Started by ●December 29, 2003
Reply by ●December 29, 20032003-12-29
Sean Whitesell wrote:> My code is writting data to a CompactFlash card. I can see the data > with WinHex. But, windows does not acknowledge the file. I'm using > the same functions as examples that work elsewhere in the project. I > need help analyzing the FAT info to see where the problem is so I know > where the problem lies in the code. I have read the FAT specs and > compared my file to good files and the differences are just not > evident. Any help on this would be most appreciated. I'm really > under the gun here.If you create an empty FAT volume on your system and mount it on a win box, doe it appear? If not, make an empty FAT volume on the win box and compare it with yours bit-by-bit. Also run chkdisk/scandisk on it and windows might be able to tell you what's wrong. Once you get an empty FAT volume to mount with no errors, write a trivial file. Again, if it won't mount or show, write the same trivial file on the win box and compare the 2 volumes. If it seems to work, be sure to run chkdisk/scandisk to make sure.
Reply by ●December 29, 20032003-12-29
> My code is writting data to a CompactFlash card. I can see the data > with WinHex. But, windows does not acknowledge the file. I'm usingAsk these questions, in this order: Is there a partition table on the disk, or did you use a "big floppy" format? You should have an MBR on the card, i.e. it should be a "hard disk" format card, not a "big floppy". Does Windows mount the volume successfully? No-> Check the MBR contents. If OK, check the LBR contents. Run Scandisk on the volume and in particular look at what volume size is reported. Yes-> Start at the directory entry. Is the file in the root directory? If not, you're running before you can walk. Create an empty entry in the root directory. I also suggest using an old version of Norton Disk Editor for DOS to inspect your card. It has an inbuilt FAT filesystem implementation and it's most useful for browsing sectors in a "cooked" mode, interpreting raw data as FAT, directory entries, LBR, MBR, ...
Reply by ●December 30, 20032003-12-30
>Is there a partition table on the disk, or did you use a "big floppy" >format? >You should have an MBR on the card, i.e. it should be a "hard disk" >format card, not a "big floppy".It works either way. In fact, Windows, when formatting a CF card does not write an MBR but starts with the partition directly (i.e. the big floppy aproach is used). Markus
Reply by ●December 30, 20032003-12-30
> >You should have an MBR on the card, i.e. it should be a "hard disk" > >format card, not a "big floppy". > > It works either way. In fact, Windows, when formatting a CF card doesIt may work either way under some circumstances, but _all_ embedded equipment uses the hard disk type format for removable media. Why behave strangely when there is a known standard to follow?
Reply by ●December 30, 20032003-12-30
>> >You should have an MBR on the card, i.e. it should be a "hard disk" >> >format card, not a "big floppy". >> >> It works either way. In fact, Windows, when formatting a CF card does > >It may work either way under some circumstances, but _all_ embedded >equipment uses the hard disk type format for removable media. Why >behave strangely when there is a known standard to follow?I respectfully disagre. I just checked. My digital camera (a cannon PowerShot S45) which I'd say should run under the term "embedded equipment" definately formats the media the "big floppy" way. It accepts both formats which is wise cause both formats IMHO seem to be widespread used. Then, considereing that Windows formats CF's the big floopy way I really think that it's not a good idea to exclusively support MBR based media in an embedded system cause the likelyhood that an end user formats a CF in a Windows system is quite big. To make things even worse, XP defaults to format CompactFlash cards with FAT32 ! That's the main reason why I also support FAT32 in my FAT implementation (which btw. supports partitioning/formatting both kind of media). This implementation does not support long filenames but ignores them if present. Markus
Reply by ●December 30, 20032003-12-30
> I just checked. My digital camera (a cannon PowerShot S45) which I'd > say should run under the term "embedded equipment" definately formats > the media the "big floppy" way. It accepts both formats which is wiseHow did you determine this, btw? It is not uncommon for Windows hosts to show you only the int 24/25h "personality" of an inserted card, i.e. no int 13h support - which means you can never see the MBR. Example of drivers that work this way: Microtech DPCM-USB multi-card reader/writer, but I'm aware of several others that have the same behavior (just don't have their names to hand). In testing literally hundreds of digital cameras for interoperability, we never encountered one single camera that uses "big floppy" format.> cause both formats IMHO seem to be widespread used. Then, considereing > that Windows formats CF's the big floopy way I really think that it'sNo! If I format a card on my Windows systems, if it already has an MBR Windows will leave the MBR there. That is with either a PCMCIA adapter or a USB adapter. If I destroy a card - zero it out - and then use Windows to format it, the behavior depends on what I'm using to connect the card to the Windows PC (and also the Windows version): * PCMCIA card - Needs to be partitioned with FDISK and then formatted. Haven't attempted this under NT-class Windows. * USB reader with its own format utility - Right-clicking the volume in My Computer and selecting Format invokes the OEM's format utility. An MBR is automatically created. * USB reader without a format utility, using generic storage class driver - It winds up as a USB-floppy type volume. Various other points come to mind, also, e.g. - will not work on systems using True-IDE boot mode. Your point about be liberal with what you accept and constrained with what you generate is well taken, but in this case the conservative approach is _always_ to write MBR-style cards. Further, some formats (e.g. SSFDC) have hard-encoded in the format specification a requirement to precede the filesystem with an MBR. Truly, it is much safer to work with "hard disk" format.
Reply by ●December 30, 20032003-12-30
larwe@larwe.com (Lewin A.R.W. Edwards) wrote in message news:<608b6569.0312300657.6f3e8ade@posting.google.com>...> > >You should have an MBR on the card, i.e. it should be a "hard disk" > > >format card, not a "big floppy". > > > > It works either way. In fact, Windows, when formatting a CF card does > > It may work either way under some circumstances, but _all_ embedded > equipment uses the hard disk type format for removable media. Why > behave strangely when there is a known standard to follow?I assume this made-up "big floppy" and "hard disk" terminology serves mainly to confuse everyone? It's perfectly valid to have a fixed disc (media type 0xF8) with or without a partition table,and not unusual at all to have a partition table with just one of the four entries occupied - pointing to a fixed disc FAT image anyway,which always seemed a bit pointless to me. Conversely the other media type bytes (0xF9/FC/FD/FE/FF) for removable media can't have partition tables.It's just that flash cards from cameras etc are considered by Windows et al as a 'fixed disc' but which just happens to be removable! Sprow.
Reply by ●December 30, 20032003-12-30
Sprow <news@sprow.co.uk> wrote:> I assume this made-up "big floppy" and "hard disk" terminology serves > mainly to confuse everyone?Not really. The technical distinction is, of course, presence or absence of an MBR on the medium. Actual floppy disks (5.25", and their not quite so floppy 3.5" offspring) never have an MBR, which is why the no-MBR way of creating a file system on a medium gained the nickname "big floppy". No confusion to be found here. OTOH, the format with a partition table and a single primary partition being referred to as "hard disk" is indeed a bit of a misnomer. It had better be called the "partitioned" style of formatting a medium.> It's perfectly valid to have a fixed disc (media type 0xF8) with or > without a partition table,Is it? So how would the system know not to treat the bytes in the relevant part of the boot code of a big-floppy medium as a partition table?> Conversely the other media type bytes (0xF9/FC/FD/FE/FF) for > removable media can't have partition tables.... but since each of those is inherently tied to a particular floppy disk format / density /sidedness, they may not be available for use with other formats that don't match any of the ancient floppy disk formats.> It's just that flash cards from cameras etc are considered by > Windows et al as a 'fixed disc' but which just happens to be > removable!Windows indeed allows this superficially self-contradictory state of affairs --- but some other systems, at least traditionally, didn't. If memory serves, OS/2 was one system that strictly refused to treat anything but "big-floppy" formatted media as removable. At that same time, Windows didn't recognize anything big-floppy at all, causing never-ending friction between these two systems, e.g. for users of MO drives. -- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
Reply by ●December 30, 20032003-12-30
> I assume this made-up "big floppy" and "hard disk" terminology serves > mainly to confuse everyone?You assume wrong, Grasshopper. It's a reasonable qualitative way to differentiate between the two format methods, and it was at one stage the way DOS programmers talked about the two. I believe the first time I read it in a formal document was an Iomega whitepaper.> without a partition table,and not unusual at all to have a partition > table with just one of the four entries occupied - pointing to a fixedThat's really irrelevant; the number of entries in the ptable is neither here nor there. The point is, embedded devices generate and look for a partition table (in the main). It's a better interoperability decision to format the card with an MBR and a single partition spanning the entire disk, than simply to commence with an LBR at physical sector 0. Yes, either are validly formatted disks, but there's a range of circumstances under which the latter won't work, whereas the former is the "industry standard" for cases where there is no actual formal standard. And in some cases, flash media format specifications MANDATE that an MBR be present; in which case, it is perfectly legal and expected that if you put your MBR-less card in a compliant appliance, that appliance will fall over and die. Note that every consumer appliance with removable flash and a reformat command in firmware that I have tested (which is a *large* number) generates an MBR. You can be practically certain that /dev/sda1 will mount (if sda is a card-reader containing a card formatted in a piece of consumer electronics). You can be practically certain that /dev/sda won't.