linux-kernel - Re: CONFIG_VFAT_FS

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: <alpine.LSU.2.00.0907030134291.17183@fbirervta.pbzchgretzou.qr>
Date:	Fri, 3 Jul 2009 01:46:37 +0200 (CEST)
From:	Jan Engelhardt <jengelh@...ozas.de>
To:	Theodore Tso <tytso@....edu>
cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Pavel Machek <pavel@....cz>, tridge@...ba.org,
	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
	john.lanza@...ux.com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel@...r.kernel.org,
	Dave Kleikamp <shaggy@...ux.vnet.ibm.com>, corbet@....net,
	jcm@...masters.org
Subject: Re: CONFIG_VFAT_FS_DUALNAMES regressions

On Friday 2009-07-03 01:17, Jan Engelhardt wrote:

>
>On Wednesday 2009-07-01 16:05, Theodore Tso wrote:
>>On Wed, Jul 01, 2009 at 12:25:58PM +0100, Alan Cox wrote:
>>
>>> (most *FAT using products don't use Microsofts
>>> implementation). Testing it versus Windows and saying it works is
>>> not really adequate. Thats what ACPI and BIOS people do that *we*
>>> moan about all the time.
>>
>>[...]
>>The other big user I can think of are digital cameras, but (a)
>>normally most users read from them and then delete the pictures, and
>>rarely write to media meant for a digital camera, and (b) the DCIM
>>standard for digital cameras explicitly only supports 8.3 filenames
>>and so digital camera manufacturers explicitly don't need to deal with
>>Long File Names at all.  (Hmm.... I wonder why....)
>>[...]
>>Ultimately, though, requiring that every single possible device be
>>tested is probably not reasonable, so the best way to do this testing
>>is the way do most of our testing; we do basic due diligence, but then
>>we merge it into mainline and let our huge user community try it out.
>
>
>Yes, here is your precedent case. The DUALNAMES patch breaks the
>operation on my Fujifilm Finepix A210 digital camera.

Adding to that, I've just run it against every possible USB device I 
could dig up in my room (i.e. one more for now).

It also breaks with the Tekmax T-1000/TMP-1000 (nicknamed 
"ioneit"/"i-one-it"/"i-want-it") digital audio player. Its built-in 
directory browser does display the copied file (see below), but does not 
want to play it nor enqueue it into the playlist.

Again, a simple copy operation was performed — this time for both 
8.3 and long names, i.e.:

  $ cp working.mp3 TEST0000.mp3
  $ cp working.mp3 TEST12345678.mp3

None of the dualnames=n-created files were accepted.

(Combinations that worked: 2.6.29.5-w/o-dualnames-patch, and
2.6.31-rc1+dualnames=y)
--
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/