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: <20090709104228.7821e2f0@lxorguk.ukuu.org.uk>
Date:	Thu, 9 Jul 2009 10:42:28 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	tridge@...ba.org
Cc:	Martin Steigerwald <Martin@...htvoll.de>,
	Jan Engelhardt <jengelh@...ozas.de>,
	Theodore Tso <tytso@....edu>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Pavel Machek <pavel@....cz>, 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, James.Bottomley@...senpartnership.com
Subject: Re: CONFIG_VFAT_FS_DUALNAMES regressions

> no, when the vendors are given a clearly non-infringing way of
> implementation then I think they will go for it. The proof is that

Even if they go for the non-infringing tweak they will still end up with
patches to rip out the potentially infringing code paths.

> 'works' for all devices, except that any Linux users copying a file
> with a long name to the device get an error. That is not my idea of
> 'works'.

It fails in a controlled manner and always produces valid output as
defined by the existing devices. At the end of the day it guarantees that
I can get my file back off the USB device on any system.

What is the fundamental purpose of a USB stick - to store and *transfer*
files. Long names are a (useful) luxury. Absolute certainty of
compatibility and reliability matter more for a file system.

> functionality that it would be a very painful solution for Linux
> vendors.

How about the users - is crashing XP, confusing Win98 and other suprises
on MP3 players not painful ?

> The dualnames patch achieves a much higher degree of functionality for
> a much wider number of users. It isn't perfect, but I think it is much
> better.

If it had controlled failure cases I would agree - but it doesn't. We are
still seeing bizarre failure cases and incompatibilities with the tiny
number of people currently testing it. Who knows what it does on some
random chinese market only mp3 player ?

> again, this is validity, not non-infringment. I am not advocating a
> "you're patent is invalid" argument, as that is not certain enough. I
> am advocating a "we don't implement that" approach.

Ok - that is important and I accept that.

> The great thing about this is that it works even better with patent
> trolls. Their sole purpose in life is to derive revenue from their
> patents. If we become known as the guys who threaten that income then
> the trolls will give us a wide berth. 

Agreed

>  > - if you limit functionality silently or in an unreliable way the blame
>  >   falls on the software supplier not the patent holder or the governments
>  >   who made the bad laws (or the judges of course as software patents
>  >   in many states aren't really of political origin but judicial
>  >   over-reach)
> 
> And if we make it so that copying files to a FAT filesystem return
> -1/ENAMETOOLONG then what will that do to users? You really think
> users will have sympathy with the situation then?

You'll get a discussion "Why can't I" "Because" "Gee that sucks how do I"

Users may not be great fans of it but they do understand whose fault it
is.

"You crashed my XP server" isn't a good basis for enlightenment nor is
"Where has my thesis gone"

> and how is your preffered 'return -1/ENAMETOOLONG' for valid long
> names 'vfat'? A new filesystem name could be used, but I think that is

I didn't say it was. It isn't vfat either.

> largely cosmetic. How many Linux users, other than developers,
> actually type:
> 
>   mount -t vfat .....
> 
> I think nearly all users just rely on the auto-detection of the fs
> type. 

Fine then giving it an accurate name won't trouble them too much.

> It is the 'some naming limits' bit which is the problem. As was
> pointed out when I posted the patch that did this in May, those limits
> impact a whole lot of normal use cases.

As clearly does this patch. But the May patch at least impacted them in a
controlled defined and predictable manner. We don't know the failure
cases and we can't predict them for this newer approach.

--
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/