linux-kernel - Re: Wrong free clusters count on FAT32

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]

Date:	Sun, 22 Apr 2007 13:17:33 +0200
From:	DervishD <lkml@...vishd.net>
To:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Cc:	Juergen Beisert <juergen127@...uzholzen.de>,
	linux-kernel@...r.kernel.org
Subject: Re: Wrong free clusters count on FAT32

    Hi Ogawa :)

 * OGAWA Hirofumi <hirofumi@...l.parknet.co.jp> dixit:
> DervishD <lkml@...vishd.net> writes:
> > 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?

    The option ignores ->free_clusters by default, am I wrong? I'm not
sure about this: given that nobody cared before, chances are that this
problem didn't bite anyone, so I think that the default behaviour should
be the _old_ behaviour (that is, nofree=0, as if the option never
existed).

    Moreover, I'm not sure if Windows updates correctly or not the
free_clustes FSINFO entry, this problem has happened (by now) in a
portable device only. What I can ensure is that both the portable device
and any Windows box I've tested ignores this value and properly
calculate the real free space. Linux doesn't because it relies on an
invalid value. Again, the fault is in the portable device, but the
workaround seems common practice out there...

    So I will suggest just "nofree:0" instead of "nofree:1". And thanks
a lot for the patch :))) I'm not sure about this: given that nobody
cared before, chances are that this problem didn't bite anyone, so I
think that the default behaviour should be the _old_ behaviour (that is,
nofree=0, as if the option never existed).

    Moreover, I'm not sure if Windows updates correctly or not the
free_clustes FSINFO entry, this problem has happened (by now) in a
portable device only. What I can ensure is that both the portable device
and any Windows box I've tested ignores this value and properly
calculate the real free space. Linux doesn't because it relies on an
invalid value. Again, the fault is in the portable device, but the
workaround seems common practice out there...

    So I will suggest just "nofree:0" instead of "nofree:1". And thanks
a lot for the patch :)))

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
-
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/