linux-kernel - End of FAT directories

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <1303498136.8485.128.camel@localhost>
Date:	Fri, 22 Apr 2011 20:48:56 +0200
From:	Michael Karcher <kernel@...rcher.dialup.fu-berlin.de>
To:	linux kernel FAT <hirofumi@...l.parknet.co.jp>,
	dosfstools <daniel@...ian.org>, mtools <Alain@...ux.lu>
Cc:	linux-kernel@...r.kernel.org
Subject: End of FAT directories

Hello Linux FAT developers and developers of related tools,

there seem to be different interpretations around how to read a FAT
directory that contains an entry starting with a NUL byte before further
entries *NOT* starting with NUL bytes. I uploaded an example image of
this type to [1]. It contains three zero-byte files "WINDOWS", "IS",
"GREAT", an empty directory slot and a file with contents named "NOT".

Listing a floppy with this directory contents in Windows gives the
output "WINDOWS", "IS" and "GREAT". Mounting the image in Linux results
in four visible files. Running dosfsck on that image outputs four files,
everything OK, while Windows CHKDSK will found one lost cluster in one
chain. mdir only lists the three files Windows will find too, but when
you copy a file that needs a long name to the image using mcopy, the
file will be appended where there are enough free slots in succession,
i.e. it will not fill the single empty slot. That means mcopy allocates
space for the file, writes a directory entry for it, but mdir does not
see it afterwards. On the other hand, as soon as you add a file that
does not need a long name entry that fills the hole, mdir shows all the
files it previously didn't show.

I'm afraid this is not a pure academic post, but I write it because I
spent hours on trying to find out why I had problem to make some USB
flash drive bootable with syslinux (which follows the MS model on
loading files while booting) after copying files with the linux kernel
(which follows the Linux model, obviously), additionally dosfsck on that
stick showed quite strange results (it dived into a directory that does
no longer exist). Another incarnation is mentioned in
https://wiki.physik.fu-berlin.de/linux-minidisc/doku.php?id=himddiskformat
in the section "Filesystem Issues with some Models on Linux". Some of
the Sony devices clear only the first half of the cluster containing
that subdirectory to zeroes, which works fine if software aborts on the
first entry being zero, but obviously makes problem if the second half
of the cluster is accessed.

I would really appreciate it if all FOSS working on FAT would agree to
one behaviour, and I think we have no choice except being MS compatible
(i.e. implement the behaviour as it has always been in DOS and Windows)

Please comment.

Regards,
  Michael Karcher

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/