linux-kernel - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87bozxomqd.fsf@devron.myhome.or.jp>
Date:	Sat, 23 Apr 2011 09:06:02 +0900
From:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To:	Michael Karcher <kernel@...rcher.dialup.fu-berlin.de>
Cc:	dosfstools <daniel@...ian.org>, mtools <Alain@...ux.lu>,
	linux-kernel@...r.kernel.org
Subject: Re: End of FAT directories

Michael Karcher <kernel@...rcher.dialup.fu-berlin.de> writes:

>> Windows will stop at 4, but if windows write new entry as 4, 5- will
>> show those up as crap like linux.
> You are right. Thanks for your input. This means Windows and mtools
> behave exactly the same way (and thus mtools can not really be
> considered buggy). I expected Windows to fix up the end, but it does
> not.
>
> I still would prefer greatly if Windows and Linux at least read media
> the same way (i.e. stop on the first zeroed entry), I even have a patch
> for that somewhere around I can dig out.
> I furthermore think it is quite important for dosfsck and the linux
> kernel to behave consistent (think of valid entries after the zeroed
> entry linking to "lost clusters"). If I prepare patches for the Linux
> kernel to
>  - terminate reading at the first zeroed entry

This is acceptable (stop at zero is an simply optimization), and I'll
just care about stability and cleanness about it.

>  - making sure that if a zeroed entry gets populated, the next entry
> gets zeroed unless we hit the end of the directory (deviating from
> Windows behaviour, intentionally, to keep the filesystem consistent)

This would be unacceptable. There are several FAT implementations like
this crap, I can't honor an one of those until to decide to try to
support all of craps.

I.e. This is the out of specs anymore. Why can you say those are invalid
entries even if Windows honors those entries? And the above is simulate
Windows implementation over specs, why isn't here? For overwriting the
zeroed entry, why we have to check all entries until see next zeroed
(yeah, now, we allowed the crappy data after zeroed)?

My state is simple - the current implement should be fine.
I.e. uninitialized directory is the simply bug. (However, I can honor to
stop at zero, because it is mentioned in spec as optimization.)

> And for dosfsck to
>  - terminate reading at the first zeroed entry
>  - offer filling the remainder of a directory cluster with zero bytes.
> Would this set of patches be acceptable?

Sorry. I can't say about dosfsck, I'm not maintainer of it. Ideas,
dosfstools maintainer?
-- 
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
--
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/