[PATCH] Added CONFIG_VFAT_FS_DUALNAMES option

[Jan Engelhardt-3]

On Monday 2009-07-06 20:55, Jan Engelhardt wrote:
>>How did things go with your mp3 players?
>[...]
>As it stands, my two devices always want a valid 8.3 name.

On or about June 26, James Bottomley exchanged these words to Andrew Tridgell:
>So the patch has been tested with Vista, Windows 7 and Windows XP


Vista, 7... nothing special.

So let me fill in.

Windows 98 can't make anything of the stunted vfat entries either[3],
and there's blanks for 16-bit programs[4]. They too, it seems, always
want an 8.3 entry in any case.
It does not crash, but neither of these results is usable.

This dualnames patch just won't fly in practice.


[3] http://picpaste.de/w98dualnames.png
[4] http://picpaste.de/xpwith16bit.png
(pics kept for 7 days from now)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Jamie Lokier]

James Bottomley wrote:

> On Wed, 2009-07-01 at 14:48 +0300, Boaz Harrosh wrote:
> > On 07/01/2009 01:50 PM, tridge@... wrote:
> > > Hi Pavel,
> > >
> > > We did of course consider that, and the changes to the patch to
> > > implement collision avoidance are relatively simple. We didn't do it
> > > as it would weaken the legal basis behind the patch. I'll leave it to
> > > John Lanza (the LF patent attorney) to expand on that if you want more
> > > information.
> > >
> >
> > You completely lost me here. And I thought I did understand the patent
> > and the fix.
> >
> > what is the difference between.
> >
> > short_name = rand(sid);
> > and
> > short_name = sid++;
> >
> > Now if you would do
> > short_name = MD5(long_name);
> >
> > That I understand since short_name is some function of long_name
> > but if I'm just inventing the short_name out of my hat. In what legal
> > system does it matter what is my random function I use?
>
> We're sort of arguing moot technicalities here.  If you look at the way
> the filename is constructed, given the constraints of a leading space
> and a NULL, the need for a NULL padded leading slash extension and the
> need to put control characters in the remaining bytes, we've only got 30
> bits to play with, we're never going to avoid collisions in a space of
> up to 31 bits.

> Technically, a random function is at least as good at
> collision avoidance as any deterministic solution ...

No, it isn't.

A deterministic value based on position in the directory, or by
checking for collisions and avoiding them, will _never_ collide,
provided you limit directories to no more than 2^30 entries, which is
reasonable for FAT.

Whereas a random value can collide.
That's a fundamental technical difference.

A quick read of the Birthday Problem page on Wikipedia leads to:

    With a directory of 1000 files, not especially rare with a camera
    or MP3 players, and 30-bit random numbers:

    The probably of a collision is 0.04% [1]

    If 10000 people each have a directory of 1000 files (not
    unreasonable given the huge number of people who use FAT media),
    the probability that any of them have a collision is approximately
    100%.

   
[1] perl -e '$d = 2.0**30; $n = 1000; $x = 1; for $k (1..$n-1) { $x *= (1 - $k/$d); } printf "Probability = %f%%\n", 100*(1-$x);'

In other words, using random values you are _guaranteeing_ collisions
for a few users.

So the argument comes down to: Does it matter if there are collisions?

Tridge's testing didn't blue screen Windows XP.
Tridge's testing did run a lot of operaitons.

But Tridge isn't 10000 people doing crazy diverse things with
different devices in all sorts of systematic but different patterns
over a period of years.

Given it's technically trivial to avoid collisions completely, and
there is some risk of breakage, even though it would be rare, there
had better be a good reason for not doing it.

-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Jan Engelhardt-3]

On Monday 2009-07-06 22:26, tridge@... wrote:
>
> > Whenever a long name is created and an 8.3 name is omitted (or rather,
> > an invalid one is generated), files are displayed in the browser but
> > fail to enqueue/play.
>
>Can you confirm whether without my patch, if you put a file on the
>device that has a long name like ThisIsALongName.mp3 that the correct
>long name is displayed in the browser on the device?

Without the two of your patches everything Works As Expected™.

(With yours, the file is displayed - as in "existence" -, with longname,
but does not play.)

>If so then it would have to be a long name capable device, and in that
>case I'll have to see if I can buy one on eBay so I can have a play :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Jamie Lokier]

Jan Engelhardt wrote:

>
> On Monday 2009-07-06 20:55, Jan Engelhardt wrote:
> >>How did things go with your mp3 players?
> >[...]
> >As it stands, my two devices always want a valid 8.3 name.
>
> On or about June 26, James Bottomley exchanged these words to Andrew Tridgell:
> >So the patch has been tested with Vista, Windows 7 and Windows XP
>
>
> Vista, 7... nothing special.
>
> So let me fill in.
>
> Windows 98 can't make anything of the stunted vfat entries either[3],
> and there's blanks for 16-bit programs[4]. They too, it seems, always
> want an 8.3 entry in any case.
> It does not crash, but neither of these results is usable.
>
> This dualnames patch just won't fly in practice.
>
>
> [3] http://picpaste.de/w98dualnames.png
> [4] http://picpaste.de/xpwith16bit.png
> (pics kept for 7 days from now)

Summary of pics, for posterity:

[3] shows an MS-DOS window on a Windows 98 desktop, listing the A:
    drive:

      Microsoft(R) Windows 98
         (C)Copyright Microsoft Corp 1981-1998.

      A:\>Dir

       Datantrager in Laufwerk A: hat keine Bezeichnung
       Seriennummer des Datentragers: 4A52-570A
       Verzeichnis von A:\

      SHORT    TXT            12  06.07.09  21:57 SHORT.TXT
                              12  06.07.09  21:57
                              12  06.07.09  21:57
               3 Datai(en)                    36 Bytes
               0 Verzeichnis(se)       1.456.128 Bytes frei

      A:\>

Question: In Windows 98, is it just the MS-DOS box which cannot see
some of the filenames, or is the normal file explorer affected too?

[4] shows a old-looking Windows application, presumably 16-bit running
    on XP, with a File Selection box listing the a:\ drive.  Four
    files are shown on the a:\ drive in a selection box, but the first
    of them is completely blank.

In Windows XP, it suggests to me that the Windows API function
GetShortPathName() returns the 8.3 file name entry.  Call it an
educated guess, and I'll guess the same applies in Server 2003, Vista,
Server 2008 and Windows 7.

All those Windows versions also have GetLongPathName() which does the
reverse transformation.  Presumably that also expects the 8.3 entry to
exist.

The fact these were added in Windows 2000 implies they're not an
ancient thing from the Windows 95 era, but specifically used by
applications since Windows 2000.

-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Jan Engelhardt-3]

On Monday 2009-07-06 22:58, Jamie Lokier wrote:

>> On Monday 2009-07-06 20:55, Jan Engelhardt wrote:
>> >>How did things go with your mp3 players?
>> >[...]
>> >As it stands, my two devices always want a valid 8.3 name.
>>
>> On or about June 26, James Bottomley exchanged these words to Andrew Tridgell:
>> >So the patch has been tested with Vista, Windows 7 and Windows XP
>>
>> [Test with Windows 98, and 16-bit GDI programs under XP]
>> [3] http://picpaste.de/w98dualnames.png
>> [4] http://picpaste.de/xpwith16bit.png
>> (pics kept for 7 days from now)
>
>Summary of pics, for posterity:
>[3] shows an [...] Question: In Windows 98, is it just the MS-DOS box
>which cannot see some of the filenames, or is the normal file explorer
>affected too?

[3] shows an MS-DOS window on a Win98 desktop, having just run the
"dir" command. In the background is a Win98 explorer window, for
comparison with the dir command.
Neither of the two ways of listing the contents of a directory show
any filenames for <illegal 8.3, long name present> entries as produced
by tridge's vfat patches.

>[4] shows a old-looking Windows application, presumably 16-bit running
>    on XP, with a File Selection box listing the a:\ drive.  Four
>    files are shown on the a:\ drive in a selection box, but the first
>    of them is completely blank.

As the filename and the intro text had said..

[4] 16-bit program (Windows 3.x era) running on XP (but probably also
happens earlier). File dialog shows blank line where an entry has an
illegal 8.3 name; also as a result of the vfat aptches.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Jamie Lokier]

Jan Engelhardt wrote:

>
> On Monday 2009-07-06 22:58, Jamie Lokier wrote:
> >> On Monday 2009-07-06 20:55, Jan Engelhardt wrote:
> >> >>How did things go with your mp3 players?
> >> >[...]
> >> >As it stands, my two devices always want a valid 8.3 name.
> >>
> >> On or about June 26, James Bottomley exchanged these words to Andrew Tridgell:
> >> >So the patch has been tested with Vista, Windows 7 and Windows XP
> >>
> >> [Test with Windows 98, and 16-bit GDI programs under XP]
> >> [3] http://picpaste.de/w98dualnames.png
> >> [4] http://picpaste.de/xpwith16bit.png
> >> (pics kept for 7 days from now)
> >
> >Summary of pics, for posterity:
> >[3] shows an [...] Question: In Windows 98, is it just the MS-DOS box
> >which cannot see some of the filenames, or is the normal file explorer
> >affected too?
>
> [3] shows an MS-DOS window on a Win98 desktop, having just run the
> "dir" command. In the background is a Win98 explorer window, for
> comparison with the dir command.
> Neither of the two ways of listing the contents of a directory show
> any filenames for <illegal 8.3, long name present> entries as produced
> by tridge's vfat patches.

Indeed.  I missed the explorer window behind the MS-DOS box, because
it has a few icons but the file names are missing.  They're missing
because of modified FAT.

> >[4] shows a old-looking Windows application, presumably 16-bit running
> >    on XP, with a File Selection box listing the a:\ drive.  Four
> >    files are shown on the a:\ drive in a selection box, but the first
> >    of them is completely blank.
>
> As the filename and the intro text had said..
>
> [4] 16-bit program (Windows 3.x era) running on XP (but probably also
> happens earlier). File dialog shows blank line where an entry has an
> illegal 8.3 name; also as a result of the vfat aptches.

Your original mail didn't say about the MS-DOS box in the 98 pic,
which is why I explained it (since the pics will disappear but the l-k
mail will be archived).

I wanted to point that out because MS-DOS file access (even in a DOS
box) is different from Windows file access.

It wouldn't be surprising if modified FAT broke on MS-DOS but worked
in 16-bit Windows - but thanks for showing that it breaks 16-bit Windows too.

And then I wanted to say the XP pic wasn't an MS-DOS box like the 98 pic...

That's all.

-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Hi Jan,

 > Windows 98 can't make anything of the stunted vfat entries either[3],
 > and there's blanks for 16-bit programs[4]. They too, it seems, always
 > want an 8.3 entry in any case.
 > It does not crash, but neither of these results is usable.

Interesting! Thanks for the testing.

I didn't have a win98 test image, but I've scrounged up a copy of the
install disks now from an old MSDN subscription, and I've built a
win98 virtual machine. I stopped testing Win9X against Samba a long
time ago (along with OS/2) so I didn't have the right setup to hand.

I've now done some experiments, and I have reproduced the problem you
saw. I've also experimented with changing the
vfat_build_dummy_83_buffer() to try some other combinations. I've
found that with a simple memset(msdos_name, ' ', 11) that Win98 works
pretty well:

  http://picpaste.com/Win98-longnames.png

It does show one error though. In the DOS box directory listing on the
left notice that it shows both a long name and a short name for the
files, with the long name being a truncated form of the short
name. The normal commands like xcopy, notepad etc all seem to work
fine though, so practical compatibility seems pretty good.

The problem with that simple memset() approach with spaces is that it
would cause more crashes with WinXP. It does show that there might be
some other combination that works with both though. I'll play a bit
more and see what I can find.

 > This dualnames patch just won't fly in practice.

well, "won't fly" depends on your POV I guess. Unless we're hoping
that all the Microsoft lawyers take early retirement, I think we do
need to have some strategy to avoiding more companies having the same
problems that TomTom had.

Would it be worth it to lose VFAT compatibility with a dead OS like
Win9X?  Quite possibly it would be for a pretty large number of
vendors.

What we need to explore now is the limits of compatibility that we can
reach. Your testing has really helped with that! I'm trying to track
down a Tekmax or 'IOneIt' mp3 player but no luck on eBay yet - I don't
suppose anyone on this list will sell me one? Are they sold in Germany
somewhere Jan?

Cheers, Tridge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Jan Engelhardt-3]

On Tuesday 2009-07-07 00:24, Jamie Lokier wrote:
>
>Your original mail didn't say about the MS-DOS box in the 98 pic,
>which is why I explained it (since the pics will disappear but the l-k
>mail will be archived).

I could attach it as MIME, it's not overly large (2x8KB unmimed) thanks to
optipng postcompression. Then again I wonder which archives allow
access to such, sometimes they seem stunted enough to only handle .diffs.
I could host them myself too. Hm.
I'll allow myself to strip Cc since it's just for the archives - here
goes:

[Boaz Harrosh-5]

On 07/06/2009 11:41 PM, Jamie Lokier wrote:

> James Bottomley wrote:
>> On Wed, 2009-07-01 at 14:48 +0300, Boaz Harrosh wrote:
>>> On 07/01/2009 01:50 PM, tridge@... wrote:
>>>> Hi Pavel,
>>>>
>>>> We did of course consider that, and the changes to the patch to
>>>> implement collision avoidance are relatively simple. We didn't do it
>>>> as it would weaken the legal basis behind the patch. I'll leave it to
>>>> John Lanza (the LF patent attorney) to expand on that if you want more
>>>> information.
>>>>
>>> You completely lost me here. And I thought I did understand the patent
>>> and the fix.
>>>
>>> what is the difference between.
>>>
>>> short_name = rand(sid);
>>> and
>>> short_name = sid++;
>>>
>>> Now if you would do
>>> short_name = MD5(long_name);
>>>
>>> That I understand since short_name is some function of long_name
>>> but if I'm just inventing the short_name out of my hat. In what legal
>>> system does it matter what is my random function I use?
>> We're sort of arguing moot technicalities here.  If you look at the way
>> the filename is constructed, given the constraints of a leading space
>> and a NULL, the need for a NULL padded leading slash extension and the
>> need to put control characters in the remaining bytes, we've only got 30
>> bits to play with, we're never going to avoid collisions in a space of
>> up to 31 bits.
>
>> Technically, a random function is at least as good at
>> collision avoidance as any deterministic solution ...
>
> No, it isn't.
>
> A deterministic value based on position in the directory, or by
> checking for collisions and avoiding them, will _never_ collide,
> provided you limit directories to no more than 2^30 entries, which is

Exactly this is the key, find the real limit and enforce it.

> reasonable for FAT.
>
> Whereas a random value can collide.
> That's a fundamental technical difference.
>
> A quick read of the Birthday Problem page on Wikipedia leads to:
>
>     With a directory of 1000 files, not especially rare with a camera
>     or MP3 players, and 30-bit random numbers:
>
>     The probably of a collision is 0.04% [1]
>
>     If 10000 people each have a directory of 1000 files (not
>     unreasonable given the huge number of people who use FAT media),
>     the probability that any of them have a collision is approximately
>     100%.
>
>    
> [1] perl -e '$d = 2.0**30; $n = 1000; $x = 1; for $k (1..$n-1) { $x *= (1 - $k/$d); } printf "Probability = %f%%\n", 100*(1-$x);'
>
> In other words, using random values you are _guaranteeing_ collisions
> for a few users.
>

Thanks, I thought it was just me.

> So the argument comes down to: Does it matter if there are collisions?
>
> Tridge's testing didn't blue screen Windows XP.
> Tridge's testing did run a lot of operaitons.
>
> But Tridge isn't 10000 people doing crazy diverse things with
> different devices in all sorts of systematic but different patterns
> over a period of years.
>

What? you say there are 10,000 people with cameras that are using Linux
in the world ;-)

> Given it's technically trivial to avoid collisions completely, and
> there is some risk of breakage, even though it would be rare, there
> had better be a good reason for not doing it.
>

I wish the lawyers people would come forward, as promised,,and explain what
are the constraints on the short_name, given a long_name is present.
I'm still waiting for that private mail in my e-box. If the names do not
correspond at all but are both valid, why is that a problem?

> -- Jamie

Thanks
Boaz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Jamie Lokier]

Boaz Harrosh wrote:
> I wish the lawyers people would come forward, as promised,,and explain what
> are the constraints on the short_name, given a long_name is present.
> I'm still waiting for that private mail in my e-box. If the names do not
> correspond at all but are both valid, why is that a problem?

To be fair Tridge said there is a reason.

The only problem is we don't know what it is...

-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Boaz Harrosh-5]

On 07/07/2009 02:25 PM, Jamie Lokier wrote:

> Boaz Harrosh wrote:
>> I wish the lawyers people would come forward, as promised,,and explain what
>> are the constraints on the short_name, given a long_name is present.
>> I'm still waiting for that private mail in my e-box. If the names do not
>> correspond at all but are both valid, why is that a problem?
>
> To be fair Tridge said there is a reason.
>
> The only problem is we don't know what it is...
>

He also said someone will answer this in a private e-mail, I'm still
waiting.

> -- Jamie

Boaz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Hi Boaz,

 > He also said someone will answer this in a private e-mail, I'm still
 > waiting.

My apologies, I assumed John had sent you something.

John, can you please look at this?

Cheers, Tridge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Pavel Machek]

On Mon 2009-07-06 23:05:19, tridge@... wrote:

> Hi Jan,
>
>  > With this extra patch:
>  >
>  >  * "cp dscf4160.jpg dscf3010.jpg" works
>
> good
>
>  >  * "cp dscf4160.jpg dscF3011.jpg" does not work - i.e. cam ignores the
>  >    file without error.
>  >    Reason for that is that dscF3011 has an illegal 8.3 name
>
> yep, that's expected. I suggested a possible way of handling this to
> Hirofumi-san (ie. change the case of the name), but he prefers to keep
> things simple for now.
>
> It is probably not unreasonable to say that you should not be using
> mixed case names when you are putting files onto a device that doesn't
> understand mixed case. The reason it worked before my patch is that
> the kernel forced the case of the 8.3 name, and only retained the
> mixed case for the long name.

It worked before. You claim that devices not understanding long
filenames are now extinct, but that camera is the
counterexample. Perhaps camera vendors fear patents, too.

So the original description is bad -- it breaks also new stuff -- and
it certainly should not be default=y.

                                                                        Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Martin Steigerwald]

Am Dienstag 07 Juli 2009 schrieb tridge@...:

> I've now done some experiments, and I have reproduced the problem you
> saw. I've also experimented with changing the
> vfat_build_dummy_83_buffer() to try some other combinations. I've
> found that with a simple memset(msdos_name, ' ', 11) that Win98 works
> pretty well:
>
>   http://picpaste.com/Win98-longnames.png
>
> It does show one error though. In the DOS box directory listing on the
> left notice that it shows both a long name and a short name for the
> files, with the long name being a truncated form of the short
> name. The normal commands like xcopy, notepad etc all seem to work
> fine though, so practical compatibility seems pretty good.
>
> The problem with that simple memset() approach with spaces is that it
> would cause more crashes with WinXP. It does show that there might be
> some other combination that works with both though. I'll play a bit
> more and see what I can find.
>
>  > This dualnames patch just won't fly in practice.
>
> well, "won't fly" depends on your POV I guess. Unless we're hoping
> that all the Microsoft lawyers take early retirement, I think we do
> need to have some strategy to avoiding more companies having the same
> problems that TomTom had.

Following this thread I get more and more the impression that this patch
is playing roulette regarding compatibility with countless devices which
use fat/vfat, with different Windows versions and with countless Windows
applications including but not limited to low level filesystem check,
repair and cloning tools. And I start to get the impression that it
becomes unmanageably complex to make a clear assessment on compatibility
in all those circumstances. Thus I can't figure how a realistic assessment
on the impact of this patch could be made.

Have low level filesystem check, repair and cloning tools been checked
against the patch at all?

I think the patch actively *corrupts* perfectly fine shortname FAT
filesystems and at least for certain use scenarios even those with long
name support.

Thus I would certainly not enable it unless forced too - already just for
*technical* reasons. I probably would even default to compile my own
kernel when I find that the distribution of my choice (Debian) would enable
it.

Politically spoken I think the patch tries to workaround a problem that
better is fixed properly and causes a precedence for other politically,
juristically motivated patches. If the Linux kernel would be changed to
avoid any software patent issues I am not sure whether it would even be
able to boot anymore. As such I think the patch should not be part of
vanilla kernels.

--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[Martin Steigerwald]

Am Dienstag 07 Juli 2009 schrieb Martin Steigerwald:
> I think the patch actively corrupts perfectly fine shortname FAT
> filesystems and at least for certain use scenarios even those with long
> name support.

Well for short name FAT only if it gets a chance to. I.e. when the
filesystem is mounted as vfat.

--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Hi Martin,

 > Have low level filesystem check, repair and cloning tools been checked
 > against the patch at all?

I have tested chkdsk.exe obvious, and I have reported the bug in
chkdsk that this testing has found to Microsoft.

I haven't tested tools like ghost or 3rd party tools. I don't actually
have any of those tools myself, although I guess I could go out and
buy them. Does anyone on this list have those tools and can let me
know if they show any problems?

 > I think the patch actively *corrupts* perfectly fine shortname FAT
 > filesystems and at least for certain use scenarios even those with long
 > name support.

The patch only changes the values stored for new files created by
Linux, so I think it is going a bit far to say it "actively corrupts"
filesystems.

I am looking into the Win9X issued raised by Jan. As I mentioned in my
mail to him, it seems to work better with some different values in the
11 bytes. I'll keep looking at that, although I don't think Win9X
support is a high priority for anyone any more. After installing Win98
in a virtual machine I connected it to the windows update service to
see if there had been updates to the old install images I had, and I
found it couldn't even connect to windows update, it just throws a
page full of html errors:

  http://samba.org/tridge/Win98-update.png

When the vendor of an operating system doesn't even bother to display
a clean "sorry, you don't get updates any more" page for their OS then
I think it is safe to say that the operating system is dead and
buried.

That leaves just the 'IOneIt' MP3 player that Jan tested. I have
ordered a bunch of different cheap MP3 players from Hong Kong on eBay
to see if I can reproduce that.

 > Thus I would certainly not enable it unless forced too - already
 > just for *technical* reasons. I probably would even default to
 > compile my own kernel when I find that the distribution of my
 > choice (Debian) would enable it.

I can't speak for Debian, but I would be not surprised if they do
enable this patch. Your opinion certainly lends weight to the idea
that it should be configurable, but I don't think it leads to the
conclusion that the patch should not be in the upstream kernel at all.

 > Politically spoken I think the patch tries to workaround a problem that
 > better is fixed properly and causes a precedence for other politically,
 > juristically motivated patches.

But what is 'fixed properly'? Exactly what should be done beyond the
activism that is already trying to change the patent systems around
the world?

I am a conscientious objector when it comes to patents, so I have
never filed any patents myself. I have also fought patents in other
ways, such as the partial win that I helped with in relation to
patents in the EU anti-trust case, and I have helped quite a few
people with patent workarounds.

It would be great if the Linux community had enough clout to force
through a change in patent law, but as yet we don't. When there was
the possibility of all of the politicians blackberries in the US
getting switched off due to a patent dispute I thought that perhaps we
finally had something that would get the attention of the people who
make these silly laws. That didn't end up resulting in any significant
change, so I don't think it is reasonable to think that the threat of
Linux desktops not being able to share USB keys with Windows will
cause politicians around the world to suddenly take an interest.

 > If the Linux kernel would be changed to avoid any software patent
 > issues I am not sure whether it would even be able to boot
 > anymore.

That argument can be used with pretty much any software (both
proprietary and free), not just the Linux kernel.

The answer is that patents that are being actively litigated, such as
the VFAT patents, fall into an entirely different class than the rest
of the patents out there.

In the case of the GIF patents the correct answer was a concerted
effort to switch to a new format. That was a fantastic campaign and
largely successful.

We don't, as yet, have any equivalent campaign to get behind for these
VFAT patents. The calls for changing to a different filesystem format
are great, but they fall down in an even worse way than what I have
proposed on exactly the same issues. This hypothetical new format
won't work with cheap MP3 players, won't work with Win9X, and almost
certainly won't work with existing Windows boxes (yes, I know about
UDF, but if you actually try it you'll see it isn't the panacea some
have claimed). So in what way is it a solution, even if the new format
existed?

If you can propose a truly workable alternative then I would be
delighted to never have to think about FAT filesystems again in my
life.

Meanwhile, I have proposed what I think is the best alternative we
have at the moment. It is certainly unpalatable to have to deal with
patents at all, but I think it is better that we work around them than
to see the problems that TomTom faced spread across the Linux world.

Cheers, Tridge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Hi Jamie,

 > I think it's ok to break that compatibility if dualnames is off,
 > because that's unfortunately the best available compromise.

You probably noticed this, but the patch that has been put in only
changes the shortname setting when dualnames is off.

Cheers, Tridge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Hi Jan,

 > Without the two of your patches everything Works As Expected�1ub.
 >
 > (With yours, the file is displayed - as in "existence" -, with longname,
 > but does not play.)

As I mentioned elsewhere, I've now ordered some cheap MP3 players from
eBay to see if I can reproduce the problem. If you know of some place
online where I can also buy the same model you have in case the ones
I've ordered don't show problems, please let me know.

Cheers, Tridge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Hi Pavel,

 > It worked before. You claim that devices not understanding long
 > filenames are now extinct, but that camera is the counterexample.

I certainly never claimed that devices that don't understand long
filenames are extinct! I own more than one digital camera that doesn't
understand long filenames.

What I said in the patch help text is:

          That means that long filenames created with this option
          disabled will not be accessible at all to operating systems
          that do not understand the VFAT extensions.

that means you have to choose 8.3 names if you want to copy files onto
a SD card and have those files visible to digital cameras. That is not
actually much of a change from how things behave without my patch for
current 8.3 only cameras. As Jan discovered, cameras tend to be pretty
fussy about the format of the filenames for files. His particular
camera wants the filenames to be dscfNNNN.jpg, which means that he
needed to be careful about choosing file names with current kernels as
well.

 > Perhaps camera vendors fear patents, too.

quite likely they want to minimise their costs, and not paying for a
patent license they don't need is one way to do that. I also expect
that not many of their customers put files onto the camera from a
computer, as opposed to taking them off.

Cheers, Tridge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Pavel Machek]

On Fri 2009-07-03 09:59:35, tridge@... wrote:
> Hi Pavel,
>
>  > That's why we have ethernet checksums.
>
> which of course just changes the number of bits. The argument remains
> the same.

Ok, so what is your estimate of XP crash probability?

>  > It already _was_ perfect before you started patching it.
>
> wow, I really didn't expect the objection to my patch to be that VFAT
> is perfect!

But ... it was, and there is still possibility of just using position
in directory to avoid collisions completely.
                                                                        Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/