Jay Savage wrote:
On 4/13/05, John W. Krahn <[EMAIL PROTECTED]> wrote:
That is usually the case, but are you sure that the "sectors" are 512 bytes
in
length?
I'm comfortable with this. All the FAT16 docs say "almost always".
Clusters can be of varying sizes, but they're multiples of 512 bytes
sectors. And empirically, it works on my test data.
[snip]
I was thinking the start at sector (or cluster, as I later discovered)
boundary behavior was part of the low probability: if everything
starts on sector, files with split EOF/EOI markers must be a multiple
of 512 +/- (length(EOF)-1) bytes long. That really narrows the
choices.
[snip]
Yes. The FF D8 FF E1 string is widely used, and I've verified it for
my data with hexdump. Apparently someone's decided to use a
non-standard APPO for digital camera files. It would make sense that
they're "raw", but I haven't gone really digging through the headers
to verify that. It may be simple non-confomance to the standard.
[snip]
I haven't had any luck finding this in a useful place, either. It
seems to appear about halfway through, when it appears at all.
ThSince these are munged or deleted files to begin with, it's not
really a surprise. That's why I was hoping for a file(-system) EOF
instead fof stream EOI. I probably should have made that clearer.
I'm thinking now that I should probably just take what I can get from
the recovery I have, and postprocess the recovered files, instead of
trying to get the recovery itself to be clean.
I haven't used DOS in a while so I may be a little fuzzy on some of the
details.
Sector size is based on the media, be it hard disk, floppy disk or whatever,
and is not carved in stone although most hard disk manufacturers have
standardised on (IIRC) 512 bytes.
Cluster size is set when the media is formatted and is recorded in the boot
sector and is based on the total size of the media.
The EOF byte was used in CP/M (because CP/M didn't store the file size
anywhere) and IIRC initial versions of DOS but all later versions of DOS store
the file size with the directory entry along with the file name and all other
file meta-data.
The DOS file system is subject to fragmentation so files may not be in
contiguous clusters. The File Allocation Table determines the order of the
clusters for each file and is located just after the boot sector.
If the files are using a proprietary format then there is no guarantee that
the SOI is at the start of the cluster.
Have you tried mounting the file as a file system? Easy enough on Linux
using
a loopback device and I think it is even possible on some versions of Windows.
John
--
use Perl;
program
fulfillment
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
