FAT spurious directory entries

FAT spurious directory entries

Post by fro.. » Thu, 03 Oct 2002 21:00:12



Hi folks,

my Psion 5MX uses a (V)FAT filesystem on its CompactFlash card. Mounting
and reading it under Linux poses no problem, except that sometimes there
are spurious directory entries.

A Microsoft document specifying FAT:
http://www.nondot.org/sabre/os/files/FileSystems/FatFormat.pdf says:

    If DIR_Name[0]==0x00, then the directory entry is free (same as for
    0xE5) and there are no allocated directory entries after this one (all
    of the DIR_Name[0] bytes in all of the entries after this one are also
    set to 0).

    The special 0 value, rather than the 0xE5 value, indicates to FAT
    file system driver code that the rest of the entries in this
    directory do not need to be examined because they are all free.

It seems that this is not completely true in the Psion world: when it
marks an entry having DIR_Name[0] as 0x00, it does not erase anything
which comes after it. So in this case you must stop scanning after finding
such a 0x00 entry, or you will have old and/or random entries (in one case,
the sector seems to have been used before for a data file, which gives
quite extraordinairy file names listed!).

According to the above specification (and presuming that it is valid),
it should be safe to stop reading after a 0x00 entry anyway. The below
patch implements that, and also fixes the case in which a new directory
entry is added after or on top of such a marker.

I can imagine that this patch is seen as too dangerous, in which case I hope
that a new mount flag would be acceptable. A new patch could be made quite
easily for this.

The PsiLinux FAQ:
http://linux-7110.sourceforge.net/cgi-bin/index.cgi?url=faqs/backup_m...
claims:
    The technical reason for the misbehaving msdos filesystem is that any
    directory created by EPOC or to which EPOC has added a cluster is
    affected by this behavior. EPOC (like ancient DOS) ignores any
    directory entries following a directory entry starting with a byte
    of zeros. Linux and Windows don't and therefore see extra "files".
If this is true, really ancient floppies would exhibit the same problem.

The patch is against 2.4.19, but should apply against 2.5 kernels without
any real trouble.

Thanks,
  Frodo

--

Defenestration n. (formal or joc.):
  The act of removing Windows from your computer in disgust, usually followed
  by the installation of Linux or some other Unix-like operating system.

  linux-2.4.19-FAT-entries.patch
1K Download
 
 
 

1. removing spurious recursive directories

sir,
        i am using a sun sparc 20 machine with solaris 2.5 as O.S
some how a spurious directory (recursive infinitely ) is created.
like /apps/OpenWorks/devkit/devkit/devkit/devkit.....
this look like a link becuase when i create a subdirectory
like test anywhere in this tree it is being shown across this
entire tree.
i could not remove this spurious directory by any normal
command like rm or rm -r or unlink etc. any help will be
highly appreciated

rama murthy

2. Sis Grapic card Supports Solaris 8 or Not???

3. How to read FAT entry

4. Puuting Boot Loader on wd0 for hd0

5. Add validity check the first entry of FAT (2/5)

6. UltraSparc laptops now available in the uk

7. too many entries too many entries too mant entries in the KDE menu

8. Strange Kernel problem?

9. 12-bit FAT or 16-bit FAT for Mtools?

10. Error: "No such file or directory" on FAT paritition

11. Poor fat people are fat...because they EAT TOO MUCH

12. entries in mail directory

13. : "free_one_pmd: bad directory entry 00000200" message.