Motherboard Forums


Reply
Thread Tools Display Modes

Special FAT filesystem questions [Was: Multiple files with same filename on FAT]

 
 
Vicne
Guest
Posts: n/a
 
      11-06-2007, 11:02 PM
Hi,

I'm still in the process of understanding the special FS my PVR uses
(see "Multiple files with same filename on FAT" thread a few days
ago).
I read the spec of the MBR and BootSector / BPB, and manually walked
through these parts.
I can see that the first (and only) partition is declared the standard
way as a 16-bit FAT (06h) in the MBR.
Although, the boot sector of this partition clearly corresponds to a
FAT32 (with a few weird values in reserved fields, but well). The last
field (filesystem type) even reads "FAT32 ".

I have a few questions though regarding the FAT itself (the actual
linked list), that I'd like to submit to specialists (that's
you :-)) :
- Can anybody explain me how to determine where the FAT starts on the
disk ?
- Does anybody have an idea what the following structure is :
The first non-zero sector I find after the BS is at BE00h (offset in
bytes from start of disk) and looks like some kind of linked list on
24 (!) bits, stuffed with FF as fourth byte, like this :
FF FF 1F 09 FF FF 1F FF 04 00 00 FF FF FF 1F FF
DF 07 00 FF FF FF 1F FF 07 00 00 FF 08 00 00 FF
0A 00 00 FF FF FF 1F FF 0B 00 00 FF 0C 00 00 FF
0E 00 00 FF FF FF 1F FF 0F 00 00 FF 10 00 00 FF
11 00 00 FF 12 00 00 FF 13 00 00 FF 14 00 00 FF
15 00 00 FF 16 00 00 FF 17 00 00 FF 18 00 00 FF
....
(and there's a copy of it starting at 31200h)
I guess it's not the FAT yet, right ?
A few bytes after the end of the that copy (at 56800h precisely), what
I think is the actual FAT begins, like this :
81 00 00 00 82 00 00 00 83 00 00 00 84 00 00 00
85 00 00 00 86 00 00 00 87 00 00 00 88 00 00 00
89 00 00 00 8A 00 00 00 8B 00 00 00 8C 00 00 00
....
(and there's a copy of this one starting at 12F6200h)

Any hint or information is welcome, of course


Vicne

 
Reply With Quote
 
 
 
 
Ted Davis
Guest
Posts: n/a
 
      11-07-2007, 01:45 AM
On Tue, 06 Nov 2007 15:02:28 -0800, Vicne wrote:

> Hi,
>
> I'm still in the process of understanding the special FS my PVR uses (see
> "Multiple files with same filename on FAT" thread a few days ago).
> I read the spec of the MBR and BootSector / BPB, and manually walked
> through these parts.
> I can see that the first (and only) partition is declared the standard way
> as a 16-bit FAT (06h) in the MBR. Although, the boot sector of this
> partition clearly corresponds to a FAT32 (with a few weird values in
> reserved fields, but well). The last field (filesystem type) even reads
> "FAT32 ".


The discrepency between the file system identified by Ghost and the one
identified by XP may be significant. It may even be a clue that the real
file system is the same as the one used on the DVD, or at least similar to
it (Joliet, perhaps)- that *would* simplify data transfers. If that just
happened to be the case, you could be looking at an ISO 9660, Level 3, or
UDF (ISO/IEC 13346) file system (with or without a bridge to ISO). The
Wikipedia entries for those file systems are informative:
<http://en.wikipedia.org/wiki/ISO_9660> and
<http://en.wikipedia.org/wiki/Universal_Disk_Format>. Follow the link to
ECMA-167
(<http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-167.pdf>)
for even more depth.

--
T.E.D. ((E-Mail Removed))

 
Reply With Quote
 
 
 
 
Alexei A. Frounze
Guest
Posts: n/a
 
      11-07-2007, 06:07 AM
On Nov 6, 3:02 pm, Vicne <(E-Mail Removed)> wrote:
> Hi,
>
> I'm still in the process of understanding the special FS my PVR uses
> (see "Multiple files with same filename on FAT" thread a few days
> ago).
> I read the spec of the MBR and BootSector / BPB, and manually walked
> through these parts.
> I can see that the first (and only) partition is declared the standard
> way as a 16-bit FAT (06h) in the MBR.


This isn't very relevant to the FAT on the partition, especially if
that's the only partition out there. Don't take this discrepancy too
close to heart.

> Although, the boot sector of this partition clearly corresponds to a
> FAT32 (with a few weird values in reserved fields, but well). The last
> field (filesystem type) even reads "FAT32 ".
>
> I have a few questions though regarding the FAT itself (the actual
> linked list), that I'd like to submit to specialists (that's
> you :-)) :
> - Can anybody explain me how to determine where the FAT starts on the
> disk ?


I would strongly recommend getting a copy of the MS FAT documentation
from their web site and read through it:
http://www.microsoft.com/whdc/system...re/fatgen.mspx
It answers all the questions. Well, maybe not all, but the vast
majority of them including this one. Then, in my code which you saw,
there's a bunch of functions at the very beginning of FAT.c precisely
for this sort of purpose: GetFirstFATSectorLBA(),
GetFirstDataSectorLBA(), GetRootDirFirstSectorLBA() and the like.

> - Does anybody have an idea what the following structure is :
> The first non-zero sector I find after the BS is at BE00h (offset in
> bytes from start of disk) and looks like some kind of linked list on
> 24 (!) bits, stuffed with FF as fourth byte, like this :
> FF FF 1F 09 FF FF 1F FF 04 00 00 FF FF FF 1F FF
> DF 07 00 FF FF FF 1F FF 07 00 00 FF 08 00 00 FF
> 0A 00 00 FF FF FF 1F FF 0B 00 00 FF 0C 00 00 FF
> 0E 00 00 FF FF FF 1F FF 0F 00 00 FF 10 00 00 FF
> 11 00 00 FF 12 00 00 FF 13 00 00 FF 14 00 00 FF
> 15 00 00 FF 16 00 00 FF 17 00 00 FF 18 00 00 FF
> ...


If you read the doc, you'll know it's effectively FAT28, look for 28
in the doc.
Seems like I have a minor bug in my code: I don't zero the 4 top bits
in GetFATEntry() (or its callers) and I zero them out in
SetFATEntry(). As per the doc both things aren't quite right. So, on
your HDD my code will have problems because of this (and the wrong
partition type, to begin with).

> (and there's a copy of it starting at 31200h)
> I guess it's not the FAT yet, right ?


Could be a copy. Check the bootsector for the number of FAT copies.

> A few bytes after the end of the that copy (at 56800h precisely), what
> I think is the actual FAT begins, like this :
> 81 00 00 00 82 00 00 00 83 00 00 00 84 00 00 00
> 85 00 00 00 86 00 00 00 87 00 00 00 88 00 00 00
> 89 00 00 00 8A 00 00 00 8B 00 00 00 8C 00 00 00
> ...
> (and there's a copy of this one starting at 12F6200h)
>
> Any hint or information is welcome, of course


HTH,
Alex

 
Reply With Quote
 
Vicne
Guest
Posts: n/a
 
      11-07-2007, 08:26 AM
On Nov 7, 2:45 am, Ted Davis <(E-Mail Removed)> wrote:

> The discrepency between the file system identified by Ghost and the one
> identified by XP may be significant. It may even be a clue that the real
> file system is the same as the one used on the DVD, or at least similar to
> it (Joliet, perhaps)- that *would* simplify data transfers.


Thanks for your reply.
Nevertheless, preliminary analysis make me think this disk has a "99%"
compatible FAT32 format. First mount attempts show that XP can mount
it, navigate directories and read most of the files OK. The "weird"
symptoms are random-looking or absent file timestamps, multiple
entries with the same name and disk-ruining chkdsk in case you let it
run :-)

Thanks for the suggestion anyway.

Vicne

 
Reply With Quote
 
Vicne
Guest
Posts: n/a
 
      11-07-2007, 09:16 AM
On Nov 7, 7:07 am, "Alexei A. Frounze" <(E-Mail Removed)> wrote:
> This isn't very relevant to the FAT on the partition, especially if
> that's the only partition out there. Don't take this discrepancy too
> close to heart.


Noted :-)


> I would strongly recommend getting a copy of the MS FAT documentation
> from their web site and read through it:http://www.microsoft.com/whdc/system...re/fatgen.mspx
> It answers all the questions. Well, maybe not all, but the vast
> majority of them including this one.


Oh yes indeed. That's much more complete than the few pages I worked
with. Thanks for the pointer.


> > FF FF 1F 09 FF FF 1F FF 04 00 00 FF FF FF 1F FF
> > DF 07 00 FF FF FF 1F FF 07 00 00 FF 08 00 00 FF
> > 0A 00 00 FF FF FF 1F FF 0B 00 00 FF 0C 00 00 FF
> > 0E 00 00 FF FF FF 1F FF 0F 00 00 FF 10 00 00 FF
> > 11 00 00 FF 12 00 00 FF 13 00 00 FF 14 00 00 FF
> > 15 00 00 FF 16 00 00 FF 17 00 00 FF 18 00 00 FF
> > ...

>
> If you read the doc, you'll know it's effectively FAT28, look for 28
> in the doc.


I quickly browsed the doc and I swear I'll read it thoroughly :-), but
reading your answer, it strikes me that the spec speaks about 28
"address bits" indeed, while I observe 24 a full FF byte after 3
variable ones...

> Seems like I have a minor bug in my code: I don't zero the 4 top bits
> in GetFATEntry() (or its callers) and I zero them out in
> SetFATEntry(). As per the doc both things aren't quite right. So, on
> your HDD my code will have problems because of this (and the wrong
> partition type, to begin with).


Oh, so "I" found a bug without even compiling the code ? :-)

> > (and there's a copy of it starting at 31200h)
> > I guess it's not the FAT yet, right ?

>
> Could be a copy. Check the bootsector for the number of FAT copies


It says 2.

But what I find strange is that I have somthing like :
"FAT24" (1st copy)
"FAT24" (2nd copy)
"FAT32" (1st copy)
"FAT32" (2nd copy)

The "FAT24" is only about 300 sectors long while the "FAT32" is about
38000 sectors long.


You see, I'm wondering if there isn't a kind of proprietary structure
that would replace or complement the FAT in case of files > 4Gb, that
would create dummy directory entries (with duplicate filenames) in the
directory and would consist of a "chain of files" or something, stored
before the FAT.

On the other hand, I'm just a newbie regarding this as you know, so
maybe I just can't see the obvious... I'll definitely read the doc and
the relevant code you pointed me to, to see where exactly the boot
sector says the FAT should begin.
Hopefully, I'll start to write some code next week-end to test things
out.

Thanks a lot for your time and help. It's much appreciated.


Vicne

PS: BTW, Alex, do you have a recommendation regarding the OS for
compiling and running your code ?
I first planned to use FreeDOS but it seems it messed with my PVR
clone disk (FreeDOS now appears in the first copy of the boot
sector !). Moreover, I tried to copy a (non-duplicate) Mpeg file with
it and the copy was truncated, while both XP and Linux performed the
full copy without any problem.
Consequently, I now plan to use the MS-DOS bundled with Win98 (boot on
floppy, "fdisk/format/sys c:" on the destination HD and copy over
utils from the oldmsdos directory of Win98 CD.
What do you think ? V.

 
Reply With Quote
 
Alexei A. Frounze
Guest
Posts: n/a
 
      11-07-2007, 10:36 AM
On Nov 7, 1:16 am, Vicne <(E-Mail Removed)> wrote:
> On Nov 7, 7:07 am, "Alexei A. Frounze" <(E-Mail Removed)> wrote:
>
> > This isn't very relevant to the FAT on the partition, especially if
> > that's the only partition out there. Don't take this discrepancy too
> > close to heart.

>
> Noted :-)
>
> > I would strongly recommend getting a copy of the MS FAT documentation
> > from their web site and read through it:http://www.microsoft.com/whdc/system...re/fatgen.mspx
> > It answers all the questions. Well, maybe not all, but the vast
> > majority of them including this one.

>
> Oh yes indeed. That's much more complete than the few pages I worked
> with. Thanks for the pointer.
>
> > > FF FF 1F 09 FF FF 1F FF 04 00 00 FF FF FF 1F FF
> > > DF 07 00 FF FF FF 1F FF 07 00 00 FF 08 00 00 FF
> > > 0A 00 00 FF FF FF 1F FF 0B 00 00 FF 0C 00 00 FF
> > > 0E 00 00 FF FF FF 1F FF 0F 00 00 FF 10 00 00 FF
> > > 11 00 00 FF 12 00 00 FF 13 00 00 FF 14 00 00 FF
> > > 15 00 00 FF 16 00 00 FF 17 00 00 FF 18 00 00 FF
> > > ...

>
> > If you read the doc, you'll know it's effectively FAT28, look for 28
> > in the doc.

>
> I quickly browsed the doc and I swear I'll read it thoroughly :-), but
> reading your answer, it strikes me that the spec speaks about 28
> "address bits" indeed, while I observe 24 a full FF byte after 3
> variable ones...
>
> > Seems like I have a minor bug in my code: I don't zero the 4 top bits
> > in GetFATEntry() (or its callers) and I zero them out in
> > SetFATEntry(). As per the doc both things aren't quite right. So, on
> > your HDD my code will have problems because of this (and the wrong
> > partition type, to begin with).

>
> Oh, so "I" found a bug without even compiling the code ? :-)


*I* found because I looked at the doc and code. You only guided me to
do so.

> > > (and there's a copy of it starting at 31200h)
> > > I guess it's not the FAT yet, right ?

>
> > Could be a copy. Check the bootsector for the number of FAT copies

>
> It says 2.
>
> But what I find strange is that I have somthing like :
> "FAT24" (1st copy)
> "FAT24" (2nd copy)
> "FAT32" (1st copy)
> "FAT32" (2nd copy)
>
> The "FAT24" is only about 300 sectors long while the "FAT32" is about
> 38000 sectors long.


I don't know. Poke around. See if those things make sense, describe
some data structure.

> You see, I'm wondering if there isn't a kind of proprietary structure
> that would replace or complement the FAT in case of files > 4Gb, that
> would create dummy directory entries (with duplicate filenames) in the
> directory and would consist of a "chain of files" or something, stored
> before the FAT.


Could be, although if you're certain with the previous discoveries
that big files are just equally named 4G pieces, then it would be odd
to have a different accounting for those 2nd and further parts. Then
again, remembering the ext2fs-like FS, maybe not. It was something
like:
1st block/cluster/whatever of every file:
- file data
- ptr to block of N ptrs to next N data blocks
- ptr to block of N ptrs to N blocks of N ptrs to next N*N data blocks
- ptr to ... next N*N*N data blocks

> On the other hand, I'm just a newbie regarding this as you know, so
> maybe I just can't see the obvious... I'll definitely read the doc and
> the relevant code you pointed me to, to see where exactly the boot
> sector says the FAT should begin.
> Hopefully, I'll start to write some code next week-end to test things
> out.
>
> Thanks a lot for your time and help. It's much appreciated.
>
> Vicne
>
> PS: BTW, Alex, do you have a recommendation regarding the OS for
> compiling and running your code ?


Compiling: DOS or 32-bit Windows (9x, 2k, xp).
Running: DOS or bare machine with BIOS only.

Read the documentation to see what tools you need and how things are
compiled.

> I first planned to use FreeDOS but it seems it messed with my PVR
> clone disk (FreeDOS now appears in the first copy of the boot
> sector !). Moreover, I tried to copy a (non-duplicate) Mpeg file with
> it and the copy was truncated, while both XP and Linux performed the
> full copy without any problem.
> Consequently, I now plan to use the MS-DOS bundled with Win98 (boot on
> floppy, "fdisk/format/sys c:" on the destination HD and copy over
> utils from the oldmsdos directory of Win98 CD.
> What do you think ? V.


That environment should be safe so long as you don't write anything to
the camera's disk with DOS.
Actually, you could greatly simplify your life by simply taking the
raw image of that drive and tweaking the test code in image.c to the
drive's geometry. That way you can use the test code to "mount" the
image and work with it. The test code is portable C code (no ASM, no
BIOS calls to do disk I/O) which you can easily tweak and debug under
any OS you want. See imgcpy.c. It was written to copy files to/from a
disk image file, almost what you need (you only need to figure out the
details of the FS and tweak FAT.c to work with it and duplicated
names). Just get fattest and imgcpy compiled and working as-is and
then use your image instead of the test one and start digging,
tweaking, etc.

Alex

 
Reply With Quote
 
Maxim S. Shatskih
Guest
Posts: n/a
 
      11-07-2007, 10:42 AM
> - Can anybody explain me how to determine where the FAT starts on the
> disk ?


The ReservedSectors BPB field is the number of sectors from volume start to the
first FAT. It is usually 1 or sometimes 2 for FAT32 (FAT32 has an FsInfo sector
which is not used by Windows NT's FASTFAT).

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
(E-Mail Removed)
http://www.storagecraft.com

 
Reply With Quote
 
Ted Davis
Guest
Posts: n/a
 
      11-07-2007, 01:48 PM
On Wed, 07 Nov 2007 00:26:29 -0800, Vicne wrote:

> On Nov 7, 2:45 am, Ted Davis <(E-Mail Removed)> wrote:
>
>> The discrepency between the file system identified by Ghost and the one
>> identified by XP may be significant. It may even be a clue that the real
>> file system is the same as the one used on the DVD, or at least similar
>> to it (Joliet, perhaps)- that *would* simplify data transfers.

>
> Thanks for your reply.
> Nevertheless, preliminary analysis make me think this disk has a "99%"
> compatible FAT32 format. First mount attempts show that XP can mount it,
> navigate directories and read most of the files OK. The "weird" symptoms
> are random-looking or absent file timestamps, multiple entries with the
> same name and disk-ruining chkdsk in case you let it run :-)
>

All of which are indications that it is *not* FAT32.

--
T.E.D. ((E-Mail Removed))


 
Reply With Quote
 
Maxim S. Shatskih
Guest
Posts: n/a
 
      11-07-2007, 07:01 PM
> Although, the boot sector of this partition clearly corresponds to a
> FAT32 (with a few weird values in reserved fields, but well). The last
> field (filesystem type) even reads "FAT32 ".


Can you provide us with the exact Extended BPB values?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
(E-Mail Removed)
http://www.storagecraft.com

 
Reply With Quote
 
Matt
Guest
Posts: n/a
 
      11-08-2007, 07:16 PM
Alexei A. Frounze wrote:
> On Nov 7, 1:16 am, Vicne <(E-Mail Removed)> wrote:
>> On Nov 7, 7:07 am, "Alexei A. Frounze" <(E-Mail Removed)> wrote:
>>
>>> This isn't very relevant to the FAT on the partition, especially if
>>> that's the only partition out there. Don't take this discrepancy too
>>> close to heart.

>> Noted :-)
>>
>>> I would strongly recommend getting a copy of the MS FAT documentation
>>> from their web site and read through it:http://www.microsoft.com/whdc/system...re/fatgen.mspx
>>> It answers all the questions. Well, maybe not all, but the vast
>>> majority of them including this one.

>> Oh yes indeed. That's much more complete than the few pages I worked
>> with. Thanks for the pointer.
>>
>>>> FF FF 1F 09 FF FF 1F FF 04 00 00 FF FF FF 1F FF
>>>> DF 07 00 FF FF FF 1F FF 07 00 00 FF 08 00 00 FF
>>>> 0A 00 00 FF FF FF 1F FF 0B 00 00 FF 0C 00 00 FF
>>>> 0E 00 00 FF FF FF 1F FF 0F 00 00 FF 10 00 00 FF
>>>> 11 00 00 FF 12 00 00 FF 13 00 00 FF 14 00 00 FF
>>>> 15 00 00 FF 16 00 00 FF 17 00 00 FF 18 00 00 FF
>>>> ...
>>> If you read the doc, you'll know it's effectively FAT28, look for 28
>>> in the doc.

>> I quickly browsed the doc and I swear I'll read it thoroughly :-), but
>> reading your answer, it strikes me that the spec speaks about 28
>> "address bits" indeed, while I observe 24 a full FF byte after 3
>> variable ones...
>>
>>> Seems like I have a minor bug in my code: I don't zero the 4 top bits
>>> in GetFATEntry() (or its callers) and I zero them out in
>>> SetFATEntry(). As per the doc both things aren't quite right. So, on
>>> your HDD my code will have problems because of this (and the wrong
>>> partition type, to begin with).

>> Oh, so "I" found a bug without even compiling the code ? :-)

>
> *I* found because I looked at the doc and code. You only guided me to
> do so.
>
>>>> (and there's a copy of it starting at 31200h)
>>>> I guess it's not the FAT yet, right ?
>>> Could be a copy. Check the bootsector for the number of FAT copies

>> It says 2.
>>
>> But what I find strange is that I have somthing like :
>> "FAT24" (1st copy)
>> "FAT24" (2nd copy)
>> "FAT32" (1st copy)
>> "FAT32" (2nd copy)
>>
>> The "FAT24" is only about 300 sectors long while the "FAT32" is about
>> 38000 sectors long.

>
> I don't know. Poke around. See if those things make sense, describe
> some data structure.
>
>> You see, I'm wondering if there isn't a kind of proprietary structure
>> that would replace or complement the FAT in case of files > 4Gb, that
>> would create dummy directory entries (with duplicate filenames) in the
>> directory and would consist of a "chain of files" or something, stored
>> before the FAT.

>
> Could be, although if you're certain with the previous discoveries
> that big files are just equally named 4G pieces, then it would be odd
> to have a different accounting for those 2nd and further parts. Then
> again, remembering the ext2fs-like FS, maybe not. It was something
> like:
> 1st block/cluster/whatever of every file:
> - file data
> - ptr to block of N ptrs to next N data blocks
> - ptr to block of N ptrs to N blocks of N ptrs to next N*N data blocks
> - ptr to ... next N*N*N data blocks
>
>> On the other hand, I'm just a newbie regarding this as you know, so
>> maybe I just can't see the obvious... I'll definitely read the doc and
>> the relevant code you pointed me to, to see where exactly the boot
>> sector says the FAT should begin.
>> Hopefully, I'll start to write some code next week-end to test things
>> out.
>>
>> Thanks a lot for your time and help. It's much appreciated.
>>
>> Vicne
>>
>> PS: BTW, Alex, do you have a recommendation regarding the OS for
>> compiling and running your code ?

>
> Compiling: DOS or 32-bit Windows (9x, 2k, xp).
> Running: DOS or bare machine with BIOS only.
>
> Read the documentation to see what tools you need and how things are
> compiled.
>
>> I first planned to use FreeDOS but it seems it messed with my PVR
>> clone disk (FreeDOS now appears in the first copy of the boot
>> sector !). Moreover, I tried to copy a (non-duplicate) Mpeg file with
>> it and the copy was truncated, while both XP and Linux performed the
>> full copy without any problem.
>> Consequently, I now plan to use the MS-DOS bundled with Win98 (boot on
>> floppy, "fdisk/format/sys c:" on the destination HD and copy over
>> utils from the oldmsdos directory of Win98 CD.
>> What do you think ? V.

>
> That environment should be safe so long as you don't write anything to
> the camera's disk with DOS.
> Actually, you could greatly simplify your life by simply taking the
> raw image of that drive and tweaking the test code in image.c to the
> drive's geometry. That way you can use the test code to "mount" the
> image and work with it. The test code is portable C code (no ASM, no
> BIOS calls to do disk I/O) which you can easily tweak and debug under
> any OS you want. See imgcpy.c. It was written to copy files to/from a
> disk image file, almost what you need (you only need to figure out the
> details of the FS and tweak FAT.c to work with it and duplicated
> names). Just get fattest and imgcpy compiled and working as-is and
> then use your image instead of the test one and start digging,
> tweaking, etc.
>
> Alex
>

My guess would be that there might be a short FAT24 partition for the
DVR to use for code updates, local storage etc. whilst the FAT32 is used
for the actual finished MPEGS. The FAT24 might be hidden from general
view in the same way that many computers have a hidden partition for
diagnostics code.

Matt


Matt
 
Reply With Quote
 
 
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Multiple files with same filename on FAT Vicne Embedded 41 11-02-2007 11:13 PM
Can't copy files with "foreign" characters in filename from NFS share sn00ge@hotmail.com Apple 0 11-20-2006 03:19 PM
Embeddable FAT filesystem Tim Clacy Embedded 24 12-16-2004 03:49 PM
Data and resource forks and those .filename files Tim Murray Apple 3 09-04-2004 12:32 AM
Re: [Q] FAT Filesystem On MMC Tricks Enrico Migliore Embedded 0 07-21-2003 02:00 PM


All times are GMT. The time now is 12:29 PM.


Welcome!
Welcome to Motherboard Point
 

Advertisment