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: <E1Hfc7X-00010D-09@be1.lrz>
Date:	Sun, 22 Apr 2007 15:28:50 +0200
From:	Bodo Eggert <7eggert@....de>
To:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
	Juergen Beisert <juergen127@...uzholzen.de>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Wrong free clusters count on FAT32

OGAWA Hirofumi <hirofumi@...l.parknet.co.jp> wrote:

>>  * Juergen Beisert <juergen127@...uzholzen.de> dixit:

>>> So the last free sector count is also stored. When mounting this
>>> filesystem you don't need to walk through the whole FAT to calculate
>>> the available space, you can use this "cached" value instead. And this
>>> cached value seems not to be updated in your portable device.
>>
>>     It doesn't, certainly, but Windows doesn't care. Moreover, the
>> device doesn't seem to recalculate the value on every run (unless it
>> does it lightning fast!), so maybe the number is stored elsewhere (the
>> count can be stored in many places as far as I've read, but I don't know
>> the details).

AFAIR it's stored twice on FAT32, once in a backup sector and once in the
superblock or extended superblock (don't remember, I think it was the
extended ~). It's not stored on FAT{12,16}.

>>     A mount option to force walking the FAT and getting the real info
>> could be interesting. That way, it will be only done for certain devices
>> (small disks, for example).
> 
> Yes. It seems that Windows does not update the ->free_clusters correctly.
> Probably, I think the option is good for now. What do you think about
> an attached patch?

Windows _does_ care*, it will pretend the disk to be full. Therefore the
stored value *SHOULD* be updated. (I think your patch does this.)

Recalculating the free space is a nice idea, and modern hardware might be
fast enough to recalculate the value on mount by default. (I didn't try this
for years.) Maybe the default should depend on arch?


About this patch: (news:8cwz8-2fE-13@...ed-at.bofh.it)

- usefree is a bad name (I'd suggest recalc_free instead), and your
  description is too cryptic to be understood by a non-linux FAT expert.
- You forgot to update Documentation/
-- 
Never forget: 2 + 2 = 5 for extremely large values of 2. 

Friß, Spammer: NyjnoQ@...gJr.7eggert.dyndns.org uh@...eggert.dyndns.org
 VnmVge7Vj@...xued.7eggert.dyndns.org RggsNsl@...7eggert.dyndns.org
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ