[PATCH] Added CONFIG_VFAT_FS_DUALNAMES option

[Martin Steigerwald]

Am Donnerstag 09 Juli 2009 schrieb David Newall:

> Christoph Hellwig wrote:
> > If someone really wants a patch to corrupt their filesystems they
> > know where to find it.
>
> No need for pettiness. Andrew's already intimated that he's still
> working the patch, and he's a very clever lad and knows if it corrupts
> it needs more work.
>
> What I don't understand is how anybody could be satisfied with the
> status quo. We cannot leave vfat unchanged, for that will perpetuate a
> pool of victims to be sued, and Linux loses credibility every time that
> happens. Something *must* change.
>
> What is especially attractive about Andrew's position (he said this
> more eloquently than me) is that developing a solution to avoid the
> patent will impact Microsoft revenues; and that will be most
> instructive to them. That's almost sufficient reason by itself!

Pardon me, but I just don't get how adapting software to software patents
will contribute into solving the problems they cause. Instead of
implementing a feature like long name + short name support straight
forwardly and simply one has to invent utterly complex, error prone and
ugly work-arounds that actually even limit the functionality. Actually I
do not envy Tridge for doing that job.

To me it seems that Microsoft has won if it can get Linux kernel
developers to cripple the upstream vanilla kernel in order to avoid
software patents. If it can get Linux kernel developers to accept a patch
that if activated limits interoperatibility and compatibily with uncounted
implementations of the one and only widely spread multiplatform and
multidevice data exchange filesystem out there currently. If it can get
Linux kernel developers to accept a patch that if activated actually risks
more bugs and errors and thus makes the implementation less reliable than
before.

To me it seems challenging the FAT standard by a modern replacement would
still be the best way to go. Any hours wasted into a patch like
CONFIG_VFAT_FS_DUALNAMES IMHO should be better spent with thinking about
and implementing a replacement filesystem. Of course everyone is free to
spend their time as they wish, but thats my oppinion.

The legal action of Microsoft against TomTom seems to create fear,
uncertainity and doubts once again. And giving in to that IMHO would mean
that Microsoft had already (partly) won.

Microsoft sued only TomTom regarding FAT patents upto now. Why? If they
acted like SCO they would have gone against IBM, big Linux distributors
like Novell and especially against several companies at once. I think this
might be cause that Microsoft just knows that their software patent claim
would break down if really tested. I do think that Microsoft does not want
those FAT patents to be tested in court. Cause I think they know they
would not stand a chance.

Accepting such a patch IMHO would help Microsoft to get away with seeding
fear, uncertainity and doubt and not having the software patent tested and
be made void. Actively adapting to software patents gives them a place to
be, gives those who support them your energy.

Actually I think just ignoring them would be better. Don't give your
energy to software patents. Ignore them and only defend were attacked
unless the world sees how ridiculous they really are. TomTom can remove
long name FAT from the Linux kernels they use to defend themselves if they
can't stand the trial. This would be defending where necessary. Putting a
patch in upstream Linux kernel would just be overreacting. Microsoft did
not yet attack the upstream Linux kernel. And I think they won't. At least
when they act rational. Thus IMHO there is no need to even think about
adapting it.

And I think its not the job of the upstream kernel to protect companies
that can not stand a patent trial or do not like to stand it. Its open-
source. They can remove parts of it.

Shall Microsoft attack IBM or other big companies. Shall Microsoft attack
big Linux distributors. Shall they attack the upstream Linux kernel -
however, I can't imagine an easy way to do that. Shall they ruin their
image completely - the did quite well on that with Vista already. Don't
help them not doing that. If Microsoft lawyers so desire let them go and
make Microsoft a parody like lawyers of SCO managed to do.

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

[Alan Cox]

> However, I don't think they will think it's necessary, and I'll tell
> you why.  Regardless of whether or not source code with an #ifdef'ed

They do it for existing cases in existing packages. So I'd say the
evidence is very very clearly that they will and they do, already, now,
at this moment. No speculation - go look at the packages.

> the case), either way, the *binary*, which is to say the **product**
> does not contain any of the infringing functionality or code.  Hence,

You have a GPL obligation to supply the sources used to build the binary.

> But in any case, even for a very risk-averse company, getting this
> proposed patch into mainline is useful, since at any point in time the
> company can get a version of the code without any code that might be
> claimable as being infringing by using unifdef.  So it's still a net
> win.  And if people are worried about the very small chances of

That aspect of the argument makes sense and I would agree with you. Its
one way to keep a reference implementation in tree as a patch.

> problems (which perhaps we can improve), we can fix that as future
> patches against the mainline --- which is the right way to do OSS
> development.  Given that Hirofumi-san has already decided to take this
> patch, so unless Linus decides to override his decision, this
> discussion is rapidly becoming moot in any case.

I've not seen any evidence to support this, and there seem to be other fs
maintainers deeply unhappy with the longname corrupting patch - Christoph
included.

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

[David Newall-3]

Martin Steigerwald wrote:

> Am Donnerstag 09 Juli 2009 schrieb David Newall:
>  
>> What I don't understand is how anybody could be satisfied with the
>> status quo. We cannot leave vfat unchanged, for that will perpetuate a
>> pool of victims to be sued, and Linux loses credibility every time that
>> happens. Something *must* change.
>>
>> What is especially attractive about Andrew's position (he said this
>> more eloquently than me) is that developing a solution to avoid the
>> patent will impact Microsoft revenues; and that will be most
>> instructive to them. That's almost sufficient reason by itself!
>>    
>
> Pardon me, but I just don't get how adapting software to software patents
> will contribute into solving the problems they cause.

As Andrew said, if we work around a patent without losing function we
destroy the economic value of that patent.  Nobody would pay licence
fees for a patent if there was a good work around.  As patent holders
attack us, we devalue their patents.  Eventually (probably quickly)
they'll learn not to attack us.


> Instead of
> implementing a feature like long name + short name support straight
> forwardly and simply one has to invent utterly complex, error prone and
> ugly work-arounds that actually even limit the functionality. Actually I
> do not envy Tridge for doing that job.
>  

It's not a given that working around a patent will result in something
ugly, error-prone or complex, nor that it will limit function.  But it
is true that we have to work around them.  We can't permit Linux to
violate patents (nor can we permit a serious claim of such.)  That would
cause no end of legal trouble, and would drive vendors away.  Since vfat
violates Microsoft's patent, or at least they seriously claim it does,
we have to do something.  We really have no choice.

> To me it seems that Microsoft has won if it can get Linux kernel
> developers to cripple the upstream vanilla kernel in order to avoid
> software patents.

It's still not certain that we have to cripple Linux to work around the
long filename patent.  Granted it looks sad, but Andrew is still working
on it.  If it turns out that we do have to cripple Linux, well sometimes
we win, sometimes we lose; but if don't at least try we always lose.
When we work around a patent without losing function we win big, and
Andrew said that has already happened for other patents.

> To me it seems challenging the FAT standard by a modern replacement would
> still be the best way to go.

Perhaps, but FAT is entrenched everywhere so I doubt that challenge
would even be noticed.

> Microsoft sued only TomTom regarding FAT patents upto now. Why? If they
> acted like SCO they would have gone against IBM, big Linux distributors
> like Novell and especially against several companies at once. I think this
> might be cause that Microsoft just knows that their software patent claim
> would break down if really tested. I do think that Microsoft does not want
> those FAT patents to be tested in court. Cause I think they know they
> would not stand a chance.
>  

I think you're right that Microsoft does not want their patent tested in
court, but as they have more money than anyone, they could keep a patent
case in court forever, costing both them and those they sue more and
more money.  If the other party keeps fighting they stand a real chance
of running out of money (and thus out of business); or they could
settle, as Tom Tom did.

> Accepting such a patch IMHO would help Microsoft to get away with seeding
> fear, uncertainity and doubt and not having the software patent tested and
> be made void. Actively adapting to software patents gives them a place to
> be, gives those who support them your energy.
>  
This is wrong.  Doing nothing is what helps Microsoft.

Working around their patent forces Microsoft to sue someone or else
tacitly accept that their patent has been bypassed.  If they sue, and
assuming the patent really has been bypassed, the courts can very
quickly determine that there is no violation, and then it becomes
explicit that the patent has been beaten.  Either way Microsoft would lose.


> Actually I think just ignoring them would be better.
This is also wrong.  Microsoft have sued Tom Tom, and they won't stop
there.  They'll keep picking businesses to sue; and each time they do
they'll win; and each time they win, Linux's reputation becomes
tarnished.  Eventually the manufacturers that build on Linux will move
to some other platform, which would be a disaster for us.

> And I think its not the job of the upstream kernel to protect companies
> that can not stand a patent trial or do not like to stand it. Its open-
> source. They can remove parts of it.
>  
They can remove parts, and it's odd that Tom Tom didn't do that.  Surely
8.3 filenames would have met their needs, and perhaps they will meet our
needs, too, in which case Alan's suggestion would be appropriate, namely
that we use long filenames where they already exist, but create new
files with 8.3 only.  I could live with that, and I suspect Andrew
could, too.  But I think he'll look for a better solution until he
satisfies himself that none is there to be found.  I hope he find one.

> Shall Microsoft attack IBM or other big companies. Shall Microsoft attack
> big Linux distributors. Shall they attack the upstream Linux kernel
>  

IBM?  Of course they would, and then Microsoft and IBM would
cross-licence their patents.  They've probably already done this.

Big Linux distributors?  I don't see Red Hat or Novel fighting, should
Microsoft sue.  They'd know the score, and either settle or remove the
function.

The upstream kernel developers?  I don't know.  They would if they felt
they needed to, but the truth is that they can do just as well by
attacking manufacturers who build on Linux, such as Tom Tom.  How many
more Tom Toms do you think it would take to drive manufacturers away
from Linux?  I don't think the number is large.
--
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 Wed 2009-07-08 17:42:09, tridge@... wrote:
> 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.

Ok, so it really should not be called vfat, and really 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/

[Pavel Machek]

On Thu 2009-07-09 14:13:04, tridge@... wrote:

> Hi Martin,
>
>  > The question before that would be whether anyone has a comprehensive list
>  > of those tools, cause I think there are quite many. Well at least those
>  > from bigger vendors should be tested I think. Paragon, Symantec, ...
>
> Do you happen to have any of those handy to test with?
>
>  > And has it been tested with Linux tools such as fsck.msdos, fsck.vfat,
>  > parted and partimage? I think it probably has not much effect on parted and
>  > partimage, but what about the fscks?
>
> I tested it with dosfstools (which provides the fsck.vfat on Linux
> distros) and with mtools. Both required patches to work correctly. I
> have submitted both patches to the maintainers of those packages.

Yes... so we know that your patch breaks at least

98 (completely)
XP (randomly)
mp3 players (completely)
cameras (workaround possible)
linux (patches available).

I believe my suggested help text was very fair.
                                                                        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 Freitag 10 Juli 2009 schrieb David Newall:

> Martin Steigerwald wrote:
> > Am Donnerstag 09 Juli 2009 schrieb David Newall:
> >> What I don't understand is how anybody could be satisfied with the
> >> status quo. We cannot leave vfat unchanged, for that will perpetuate
> >> a pool of victims to be sued, and Linux loses credibility every time
> >> that happens. Something *must* change.
> >>
> >> What is especially attractive about Andrew's position (he said this
> >> more eloquently than me) is that developing a solution to avoid the
> >> patent will impact Microsoft revenues; and that will be most
> >> instructive to them. That's almost sufficient reason by itself!
> >
> > Pardon me, but I just don't get how adapting software to software
> > patents will contribute into solving the problems they cause.
>
> As Andrew said, if we work around a patent without losing function we
> destroy the economic value of that patent.  Nobody would pay licence
> fees for a patent if there was a good work around.  As patent holders
> attack us, we devalue their patents.  Eventually (probably quickly)
> they'll learn not to attack us.

To me your thoughts appear to be *within* the patent approach and *thus*
implicitely saying "yes" software patents as such. Going this way I think
actually strengthen patents. The FAT patents have not yet been tested.
They might easily just be void and invalid.

But going the way you outline would be giving in to the patent claim
*before* it has even been tried and tested for validity. And thus IMHO
this strengthens the patent and it holder. If you change the upstream
kernel Microsoft can always say: "Look Linux kernel developers think that
the kernel infringed our patents."

The linux kernel has not yet been proven to infringe any FAT patent.
Microsoft claims that it does. But so did SCO claim that it contains
source of UNIX that they said they have a license for. SCO could never
prove that claim. The linux kernel community ignored SCO for exactly that
reason. Why on Earth should it handle Microsoft differently?  Just due to
its sheer size and weight in capital? The trial with TomTom just proves
nothing right now.

> > Instead of
> > implementing a feature like long name + short name support straight
> > forwardly and simply one has to invent utterly complex, error prone
> > and ugly work-arounds that actually even limit the functionality.
> > Actually I do not envy Tridge for doing that job.
>
> It's not a given that working around a patent will result in something
> ugly, error-prone or complex, nor that it will limit function.  But it
> is true that we have to work around them.  We can't permit Linux to
> violate patents (nor can we permit a serious claim of such.)  That
> would cause no end of legal trouble, and would drive vendors away.
> Since vfat violates Microsoft's patent, or at least they seriously
> claim it does, we have to do something.  We really have no choice.

Right now to me it seems that it is nowhere but clear that Linux violates
valid patents about the inner workings of FAT. Currently any work to adapt
the kernel to the FAT patents is based on the assumption that they might
be valid, not on facts.

> > To me it seems that Microsoft has won if it can get Linux kernel
> > developers to cripple the upstream vanilla kernel in order to avoid
> > software patents.
>
> It's still not certain that we have to cripple Linux to work around the
> long filename patent.  Granted it looks sad, but Andrew is still
> working on it.  If it turns out that we do have to cripple Linux, well
> sometimes we win, sometimes we lose; but if don't at least try we
> always lose. When we work around a patent without losing function we
> win big, and Andrew said that has already happened for other patents.

I just relate to what is currently available. If Tridge posts a different
patch things might be different. But right now this is just pure
speculation. So I would like to stick to what is actually there. This
patch.

> > Microsoft sued only TomTom regarding FAT patents upto now. Why? If
> > they acted like SCO they would have gone against IBM, big Linux
> > distributors like Novell and especially against several companies at
> > once. I think this might be cause that Microsoft just knows that
> > their software patent claim would break down if really tested. I do
> > think that Microsoft does not want those FAT patents to be tested in
> > court. Cause I think they know they would not stand a chance.
>
> I think you're right that Microsoft does not want their patent tested
> in court, but as they have more money than anyone, they could keep a
> patent case in court forever, costing both them and those they sue more
> and more money.  If the other party keeps fighting they stand a real
> chance of running out of money (and thus out of business); or they
> could settle, as Tom Tom did.

I think you omit that doing this would cost Microsoft really lots of
reputation. I believe that Microsoft fears testing the patent in trial and
having a long trial just as much if not more than the company it sues.

Would you buy a Unix or something else from SCO? I wouldn't. Would a
company do it? I think only if forced to by compatibility constraints. Now
SCO OpenServer or what it was called may be more replaceable than Windows,
but Windows has become replaceable in more and more use cases as well.

If Microsoft would be serious about playing the bad guy they IMHO would
pay a forbiddenly high price for it. Actually I believe this would impose
a high, probably existential risk to Microsoft. Yes, Microsoft has lots of
money. But the current economic crisis has shown how easily insane amounts
of money can be disintegrated in no time. I do think that Microsoft is
neither almighty nor immune to that.

And then they would also show even more clearly than ever the absurdities
of the current software patent law in the USA. This would strengthen
forces that work to revert that law. More politicians would see that the
software patent law must be changed.

> > Accepting such a patch IMHO would help Microsoft to get away with
> > seeding fear, uncertainity and doubt and not having the software
> > patent tested and be made void. Actively adapting to software patents
> > gives them a place to be, gives those who support them your energy.
>
> This is wrong.  Doing nothing is what helps Microsoft.

I can't continue aguing on that basis. I just stated my oppinion. You say
it is wrong. I can say your oppinion is wrong. But nothing gained by that.
No need to continue to cycle this. My oppinion is my oppinion and yours is
yours. And I don't buy your oppinion even when you present it as factual
thing.

> > Actually I think just ignoring them would be better.
>
> This is also wrong.  Microsoft have sued Tom Tom, and they won't stop

Same here. Just:

> there.  They'll keep picking businesses to sue; and each time they do
> they'll win; and each time they win, Linux's reputation becomes
> tarnished.  Eventually the manufacturers that build on Linux will move
> to some other platform, which would be a disaster for us.

You seem to know more than me. Sure I can speculate about what Microsoft
will be doing and I did. But I am pretty sure that I can not really *know*
it. Your statements sounds bold enough to suggest that you have looked
into a crystal orb of foresay. Did you?

I just point out to you: They didn't do anything else than suing TomTom
just yet. Thats fact, unless I did not notice any other trials going on.

> > Shall Microsoft attack IBM or other big companies. Shall Microsoft
> > attack big Linux distributors. Shall they attack the upstream Linux
> > kernel
>
> IBM?  Of course they would, and then Microsoft and IBM would
> cross-licence their patents.  They've probably already done this.

You really think they would? Have they been already that successful at
seeding fear, uncertainity and doubt? I bet that they would not dare to
challenge IBM on such ridiculous patents.

> Big Linux distributors?  I don't see Red Hat or Novel fighting, should
> Microsoft sue.  They'd know the score, and either settle or remove the
> function.

Sure? What about indemnification assurances regarding SCO claims that
AFAIK both Novell and RedHat offered to their customers? SCO is smaller
than Microsoft, granted. But still, those patents, the whole software
patent law in USA are ridiculous. Giving in to them would probably loose
Novell and RedHat more than is gained by testing them and having them
declared as invalid and void as they should be declared.

> The upstream kernel developers?  I don't know.  They would if they felt
> they needed to, but the truth is that they can do just as well by
> attacking manufacturers who build on Linux, such as Tom Tom.  How many
> more Tom Toms do you think it would take to drive manufacturers away
> from Linux?  I don't think the number is large.

Directly attacking upstream kernel developers IMHO would backfire even
more than suing companies. Do you really think Microsoft can risk to loose
that much reputation? Do you really think that Microsoft is ready to
handle the response of the open-source community, big news sites,
companies supporting open-source, lawyers supporting open-source? I think
they aren't and I think they know that. And thus I think they would not
dare to do it. Right know they only had a go at TomTom. To me this looks
like the behavior of coward. Apart from I think Linux including all its
surroundings isn't that weak that it needs to fear Microsoft. I think
right know its more the other way around.

Granted, speculation, but IMHO a quite plausible one. Anyway I will end it
here. And as I think there is not much more to be said without recycling
arguments I will try to refrain from any comments on arguments that have
already been rised.

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

[Jonathan Corbet]

On Fri, 10 Jul 2009 20:49:00 +0200
Martin Steigerwald <Martin@...> wrote:

> To me your thoughts appear to be *within* the patent approach and *thus*
> implicitely saying "yes" software patents as such. Going this way I think
> actually strengthen patents.

One deals with reality on reality's terms.  For the moment, software
patents exist in some parts of the world.  People are working on that,
but one cannot just stick one's fingers into one's ears and wish the
problem away.

> The FAT patents have not yet been tested.
> They might easily just be void and invalid.

The FAT patents *have* been tested, invalidated, and then revalidated.
Yes, they might still be invalid - I believe they are.  This helps a
Linux user whose products have been seized at the US border exactly
how?

> But going the way you outline would be giving in to the patent claim
> *before* it has even been tried and tested for validity. And thus IMHO
> this strengthens the patent and it holder. If you change the upstream
> kernel Microsoft can always say: "Look Linux kernel developers think that
> the kernel infringed our patents."

The point is not to give in to the claim; the point is to make it
irrelevant.  That "invalidates" the patent in a way which (1) doesn't
cost several million dollars and (2) is rather more certain in its
outcome.

> The linux kernel has not yet been proven to infringe any FAT patent.
> Microsoft claims that it does. But so did SCO claim that it contains
> source of UNIX that they said they have a license for. SCO could never
> prove that claim. The linux kernel community ignored SCO for exactly that
> reason.

The Linux community did not ignore SCO.  We looked very hard at our
code and our processes, and adopted things like the DCO very much in
response to SCO.  The whole SCO affair has, IMO, made us a lot
stronger.

SCO is a very different story, though.  Copyright infringement is
usually pretty easy to avoid - just do your own work.  Patent
infringement happens regardless of how original your work is.

> Why on Earth should it handle Microsoft differently?  Just due to
> its sheer size and weight in capital? The trial with TomTom just proves
> nothing right now.

The TomTom trial proves that companies like TomTom have no real hope of
withstanding patent attacks and nicely invalidating obnoxious patents
as a favor for the rest of us.

Perhaps (a future version of) this patch isn't the right solution to
the VFAT patent problem.  Be we do need to figure out how we can
respond to patents which are being used to attack our users.  Telling
them to take the bullet and try to invalidate the patent for us isn't
going to fly.  Neither is ignoring the problem.

I have a lot of sympathy for Alan's assertion that we can't muck up our
upstream code with hackarounds for every bit of legal obnoxiousness we
encounter.  But outright refusal of things like patent workarounds does
not help us either.  Linux is a pragmatic system; somehow, I believe,
we can find a way to minimize our patent hassles without messing up the
system as a whole.

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

[Bartlomiej Zolnierkiewicz]

On Friday 10 July 2009 21:31:27 Jonathan Corbet wrote:

> I have a lot of sympathy for Alan's assertion that we can't muck up our
> upstream code with hackarounds for every bit of legal obnoxiousness we
> encounter.  But outright refusal of things like patent workarounds does
> not help us either.  Linux is a pragmatic system; somehow, I believe,
> we can find a way to minimize our patent hassles without messing up the
> system as a whole.

Alan, Pavel and other people are suggesting pragmatic *long-term* solutions,
like moving kernel.org outside problematic geopolitical area.  Tainting *our*
code-base with (confusing for *our* users) workarounds doesn't belong in this
class of solutions.. actually no.. it is a PURE F*CKING IDIOCY..

Microsoft having patents on their *obsolete* filesystem should be *their*
problem, not *ours*.  We keep said filesystem strictly for compatibility
reasons and not because we would like to encourage hardware/software vendors
or users to use it.  Lets just update VFAT help text to mention potential
risks of using it, default it to N, rip it from defconfigs, pass it through
lawyers, remove CONFIG_VFAT_FS_DUALNAMES and move on..

When it comes to distributions if they really need they can easily deal with
the problem by simply allowing the 3-rd parties to host the repositories with
risky package (like they do with mp3 etc).

The end result is that end-users can still use full vfat, vendors are safe,
kernel developers don't waste their time on artificial problems and the blame
goes where it belong..

[ The validity of potentially bogus patents (or problems of hardware vendors
  caused by *their* decisions to use *obsolete* and patent-risky filesystem in
  their products) is an entirely different matter/discussion and it shouldn't
  be mixed with technical solutions.. ]
--
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]

Pavel Machek wrote:
> > I tested it with dosfstools (which provides the fsck.vfat on Linux
> > distros) and with mtools. Both required patches to work correctly. I
> > have submitted both patches to the maintainers of those packages.
>
> Yes... so we know that your patch breaks at least
>
...
> linux (patches available).

Ew.

Old Linux boxes don't get updates, and they don't have udev, hotplug
or auto-mounting desktops either.  They're the ones where mtools is
used on floppies.

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

[Alan Cox]

> The FAT patents *have* been tested, invalidated, and then revalidated.
> Yes, they might still be invalid - I believe they are.  This helps a
> Linux user whose products have been seized at the US border exactly
> how?

The same way as one who shipped mp3 software.

Of course they can simply remove the code that concerns them as companies
*already do*. They have specialists for this, experts who know the very
complex field of import and export regulation.

> SCO is a very different story, though.  Copyright infringement is
> usually pretty easy to avoid - just do your own work.  Patent
> infringement happens regardless of how original your work is.

Actually this is changing, large corporations stealing photographic
images and the threatening to sue the original photographer is becoming
rather common. I'm sure the same will happen in other fields too. SCO
probably did it by accident, but folks will do it deliberately too.

> I have a lot of sympathy for Alan's assertion that we can't muck up our
> upstream code with hackarounds for every bit of legal obnoxiousness we
> encounter.  But outright refusal of things like patent workarounds does
> not help us either.  Linux is a pragmatic system; somehow, I believe,
> we can find a way to minimize our patent hassles without messing up the
> system as a whole.

If you don't believe VFAT is permitted in your shipping locale you turn
it off (actually you cut the code from your source tar before build).
Utterly routine practice every day for companies shipping product into
the USA. Happens with tons of other open source software that isn't
permitted in the USA.

The pragmatic approach would be to either avoid the patent without
breaking stuff (which Tridge hasn't managed, although maybe one day he
might), or to produce something which doesn't break stuff, is reliable,
meets our quality goals but which is alternative and clearly presented as
an alternative - such as Tridge's shortname creating tridgefat variant,
which at least didn't randomly explode users data in new and novel ways.
It still needs to be an alternative not a replacement for the real thing.

Alan
--
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]

tridge@... wrote:
> I haven't tested against w2k yet. I'll need to dig through my old MSDN
> CD stack and see if I can find a w2k CD to test with. It's no longer
> offered on current MSDN subscriptions.

Windows NT-derivatives and Windows 95-derivatives use a significantly
different code base for their filesystems, even to the extent of
having different VFAT behaviour.  Hence shortnames=win95, shortname=winnt.

The last Windows 95-derivative is Windows ME, which is was released
about the same time as Windows 2000.  Windows 2000 is an NT-derivative.

So it might be worth testing against Windows ME.

I don't know what code base is used for Windows CE.  CE is still used,
on phones, PDAs and media players among other things.  Has there been
any testing against CE - current versions and old versions?

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

[Jamie Lokier]

tridge@... wrote:
> 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.

Yes, I noticed.

What I mean is if I do this, with your patch active:

    mount /dev/sdb -t vfat -o shortname=mixed

(or shortname=lower, or shortname=win95), then it's wrong to override
my shortname request "shortname=mixed", because my request means "I
need lower-case names to _appear_ lower-case on something with Windows
95-like behaviour.

When dual names cannot be created, if I specify any shortname= option
except shortname=winnt, I'd rather create a long name entry for
lower-case 8.3 names than a short name.

That's why dualnames off should change the *default* to
shortname=winnt, but not override an explicit shortname= option.

With dualnames on, the default should be shortname=mixed because that
has wider compatibility, and it's like the old Linux default when
creating names.

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

[Jamie Lokier]

Jan Engelhardt wrote:

>
> On Friday 2009-07-03 03:26, tridge@... wrote:
> >
> > > Making WINNT the default would cause many a `ls` output to just
> > > scream at me in uppercaps because there are programs that
> > > create long names with all-uppers.
> >
> >well, you could also argue that having WINNT in effect does the
> >'correct' thing. It causes ls to display the name that is actually in
> >the filesystem.
> >
> >I think the current default for VFAT on Linux is rather misleading. It
> >always displays 8.3 names as lowercase,
>
> There is no misleading in that, since VFAT is rather case-insensitive.

It's case-insensitive for searches, but:

 - With the "posix" option, you can have multiple names with different cases.

 - It still preserves case.  I've got (Linux!) devices which copy
   files from FAT flash media onto their internal hard disk which is
   ext3, and then fail to work if the files on ext3 have the wrong case.

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

[Jamie Lokier]

Jamie Lokier wrote:
> I don't know what code base is used for Windows CE.  CE is still used,
> on phones, PDAs and media players among other things.  Has there been
> any testing against CE - current versions and old versions?

Found something about Windows CE:

    On WinCE, long filenames do not need to be generated if the filename
    is 8.3 compatible: it must contain all uppercase characters, no
    unicode characters, and be no longer than 8 characters long with no
    more than a 3 character extension. For example, FILENAME.TXT would not
    generate a long filename and uses only one directory
    entry. FileName.Txt, filename.txt, and FILENAME0.TXT would all
    genenerate a long filename.

    From: http://blogs.msdn.com/medmedia/archive/2007/01/04/fat-filesystem-performance-issues.aspx

In other words, Windows CE uses the same algorithm as Windows 9x when
deciding whether to _create_ a long filename, corresponding to
shortname=mixed.

That post is from 2007, so likely to be what goes on recent CE devices.

I don't know if that means it _reads_ FAT the same way as Windows 9x,
or if they decided to do the same as shortname=mixed for maximum
compatibility with everything.  Has anyone ever checked if
shortname=winnt is what NT-derivatives like XP and Vista still do?

Obviously we care about how CE reads FAT, not when it creates long
names.  This is just a little clue that it might be the same as Windows 9x.

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

[David Newall-3]

Martin Steigerwald wrote:
> The FAT patents have not yet been tested.
> They might easily just be void and invalid.
>  

It might be invalid, but it would take a lot of money to get just the US
Patent invalidated.  Since it's probably also patented in Australia, UK,
Japan, Germany and so on, you'd need to invalidate it there, too, to
wipe out the problem, and a US decision to revoke wouldn't help much.

Don't worry about whether the patent is valid, because we can't fight
that.  Tom Tom chose not to fight the patent, which let's you know how
big we could be and still be unable to fight it.  Instead, think of ways
to side-step it.



> But going the way you outline would be giving in to the patent claim
> *before* it has even been tried and tested for validity. And thus IMHO
> this strengthens the patent and it holder. If you change the upstream
> kernel Microsoft can always say: "Look Linux kernel developers think that
> the kernel infringed our patents."
>  

Working around a patent in no way strengthens the patent claims.  Even
if it did, if we come up with an alternative that gives long and short
file names without going through the steps that Microsoft described in
their patent, then we wouldn't be violating their patent.  Remember
this: Microsoft did not patent a file system with long and short file
names.  I understand that is not even a patentable matter.  Microsoft
patented a *method* for creating long and short files, and if we don't
follow their method then their patent doesn't cover what we do.

Let's find a solution that Microsoft haven't patented, and then give
that to the world.  While it might still look like a duck, walk like a
duck and quack like a duck, we need only put the feathers on *before*
the feet, and then it isn't a duck under patent law.

>> I think you're right that Microsoft does not want their patent tested
>> in court, but as they have more money than anyone, they could keep a
>> patent case in court forever, costing both them and those they sue more
>> and more money.  If the other party keeps fighting they stand a real
>> chance of running out of money (and thus out of business); or they
>> could settle, as Tom Tom did.
>>    
>
> I think you omit that doing this would cost Microsoft really lots of
> reputation. I believe that Microsoft fears testing the patent in trial and
> having a long trial just as much if not more than the company it sues.
>  

You think Microsoft fear testing in court, yet we know otherwise because
they already did initiate action against Tom Tom.  Think what you like,
but I will stick, unimaginative thought it might be, to the real world.

> Would you buy a Unix or something else from SCO?
Let me put it this way: going back only a few years, we had no choice
over who provided local calls.  Even though almost everybody agreed they
were expensive, unfriendly and disinterested in their customers' needs,
we still bought from them.


One thing I suspect none of us would deny is that the patent system is
seriously flawed.  Sadly, that's completely irrelevant.  It's long been
accepted that the Law is an ass, but it's still the law and if you
disobey it it will slap you so hard and quickly your head will spin.
--
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/

[Jörn Engel-4]

[ Ignoring all legal and moral aspects...]

On Fri, 10 July 2009 22:40:14 +0200, Bartlomiej Zolnierkiewicz wrote:
>
> Microsoft having patents on their *obsolete* filesystem should be *their*

FAT is far from obsolete.  It is practically always the filesystem of
choice and often the only filesystem when trying to move data from one
system to another.  The next best alternatives are isofs and ext2.  And
I don't know a single digital camera, mp3 player or cellphone that
speaks either.

Jörn

--
Joern's library part 5:
http://www.faqs.org/faqs/compression-faq/part2/section-9.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/

[Jan Engelhardt-3]

On Sunday 2009-07-12 13:21, Jörn Engel wrote:

>[ Ignoring all legal and moral aspects...]
>
>On Fri, 10 July 2009 22:40:14 +0200, Bartlomiej Zolnierkiewicz wrote:
>>
>> Microsoft having patents on their *obsolete* filesystem should be *their*
>
>FAT is far from obsolete.  It is practically always the filesystem of
>choice and often the only filesystem when trying to move data from one
>system to another.  The next best alternatives are isofs and ext2.  And
>I don't know a single digital camera, mp3 player or cellphone that
>speaks either.

The next best would probably be UDF, which is already used on DVDs
and thus is implemented in a number of devices - though probably
only disc-reading ones.
There's your market hole, dear vendors.
--
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/

[OGAWA Hirofumi]

OGAWA Hirofumi <hirofumi@...> writes:

> Alan Cox <alan@...> writes:
>
>> Sure and I'd say the technical issues are simple
>>
>> - Tridge's patch breaks stuff
>> - Tridge's patch masquerades as vfat but isn't.
>>
>> We can fix those by only creating short names (but honouring existing
>> long ones) and by not claiming its vfat.
>
> As technical stand, I agree with this approach. And my poor brain can't
> consider other than technical thing, it is purely my problem though. So
> I'll try to create the patch based on first version, and I'll apply it
> instead.
>
> And could you please stop talking about other than technical issues? My
> poor brain is already overflowed.
>
> I'm a fool?  Yes, I agree.

My patch is following. Sorry. But I'm still worrying about this myself.

It seems my skill and knowledge for the issue are too small.  My time
for fat was already small before this, and honestly, I don't think I can
maintain/support all issues well.

So, finally, I thought the best for us which I can is to find new
maintainer for fat.

Could you help to find the new maintainer?

Thanks.
--
OGAWA Hirofumi <hirofumi@...>



From: tridge@...

When this option is enabled this will refuse to create new files with
long names. Accessing existing files with long names will continue to
work.

File names to be created must conform to the 8.3 format.  Mixed case is
not allowed in either the prefix or the suffix.

Signed-off-by: Andrew Tridgell <tridge@...>
[Add "lfat", comment out Kconfig]
Signed-off-by: OGAWA Hirofumi <hirofumi@...>
---

 fs/fat/Kconfig      |   11 +++++++++++
 fs/fat/namei_vfat.c |   35 ++++++++++++++++++++++++++++++-----
 2 files changed, 41 insertions(+), 5 deletions(-)

diff -puN fs/fat/Kconfig~fat-disable-longname fs/fat/Kconfig
--- fatfs-2.6-2/fs/fat/Kconfig~fat-disable-longname 2009-07-10 16:16:47.000000000 +0900
+++ fatfs-2.6-2-hirofumi/fs/fat/Kconfig 2009-07-12 12:50:52.000000000 +0900
@@ -98,3 +98,14 @@ config FAT_DEFAULT_IOCHARSET
 
   Enable any character sets you need in File Systems/Native Language
   Support.
+
+#config VFAT_NO_CREATE_WITH_LONGNAMES
+# bool "Disable creating files with long names"
+# depends on VFAT_FS
+# default n
+# help
+#  Set this to disable support for creating files or directories with
+#  names longer than 8.3 (the original DOS maximum file name length)
+#  e.g. naming a file FILE1234.TXT would be allowed but creating or
+#  renaming a file to FILE12345.TXT or FILE1234.TEXT would not
+#  be permitted.  Reading files with long file names is still permitted.
diff -puN fs/fat/namei_vfat.c~fat-disable-longname fs/fat/namei_vfat.c
--- fatfs-2.6-2/fs/fat/namei_vfat.c~fat-disable-longname 2009-07-10 16:16:47.000000000 +0900
+++ fatfs-2.6-2-hirofumi/fs/fat/namei_vfat.c 2009-07-11 16:26:24.000000000 +0900
@@ -316,6 +316,7 @@ static int vfat_create_shortname(struct
  int sz = 0, extlen, baselen, i, numtail_baselen, numtail2_baselen;
  int is_shortname;
  struct shortname_info base_info, ext_info;
+ unsigned opt_shortname = opts->shortname;
 
  is_shortname = 1;
  INIT_SHORTNAME_INFO(&base_info);
@@ -424,13 +425,22 @@ static int vfat_create_shortname(struct
  memcpy(name_res, base, baselen);
  memcpy(name_res + 8, ext, extlen);
  *lcase = 0;
+
+#ifdef CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES
+ if (is_shortname == 0)
+ return -ENAMETOOLONG;
+ if (!base_info.valid || !ext_info.valid)
+ return -EINVAL;
+ opt_shortname = VFAT_SFN_CREATE_WINNT;
+#endif
+
  if (is_shortname && base_info.valid && ext_info.valid) {
  if (vfat_find_form(dir, name_res) == 0)
  return -EEXIST;
 
- if (opts->shortname & VFAT_SFN_CREATE_WIN95) {
+ if (opt_shortname & VFAT_SFN_CREATE_WIN95) {
  return (base_info.upper && ext_info.upper);
- } else if (opts->shortname & VFAT_SFN_CREATE_WINNT) {
+ } else if (opt_shortname & VFAT_SFN_CREATE_WINNT) {
  if ((base_info.upper || base_info.lower) &&
     (ext_info.upper || ext_info.lower)) {
  if (!base_info.upper && base_info.lower)
@@ -593,15 +603,19 @@ static int vfat_build_slots(struct inode
 {
  struct msdos_sb_info *sbi = MSDOS_SB(dir->i_sb);
  struct fat_mount_options *opts = &sbi->options;
- struct msdos_dir_slot *ps;
  struct msdos_dir_entry *de;
- unsigned char cksum, lcase;
+ unsigned char lcase;
  unsigned char msdos_name[MSDOS_NAME];
  wchar_t *uname;
  __le16 time, date;
  u8 time_cs;
- int err, ulen, usize, i;
+ int err, ulen, usize;
+#ifndef CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES
+ int i;
+ struct msdos_dir_slot *ps;
+ unsigned char cksum;
  loff_t offset;
+#endif
 
  *nr_slots = 0;
 
@@ -628,6 +642,9 @@ static int vfat_build_slots(struct inode
  goto shortname;
  }
 
+#ifdef CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES
+ de = (struct msdos_dir_entry *)slots;
+#else
  /* build the entry of long file name */
  cksum = fat_checksum(msdos_name);
 
@@ -645,6 +662,7 @@ static int vfat_build_slots(struct inode
  }
  slots[0].id |= 0x40;
  de = (struct msdos_dir_entry *)ps;
+#endif
 
 shortname:
  /* build the entry of 8.3 alias name */
@@ -1074,7 +1092,11 @@ static int vfat_get_sb(struct file_syste
 
 static struct file_system_type vfat_fs_type = {
  .owner = THIS_MODULE,
+#ifdef CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES
+ .name = "lfat",
+#else
  .name = "vfat",
+#endif
  .get_sb = vfat_get_sb,
  .kill_sb = kill_block_super,
  .fs_flags = FS_REQUIRES_DEV,
@@ -1093,6 +1115,9 @@ static void __exit exit_vfat_fs(void)
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("VFAT filesystem support");
 MODULE_AUTHOR("Gordon Chaffee");
+#ifdef CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES
+MODULE_ALIAS("lfat");
+#endif
 
 module_init(init_vfat_fs)
 module_exit(exit_vfat_fs)
_
--
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 Sunday 2009-07-12 13:21, Jörn Engel wrote:
> >[ Ignoring all legal and moral aspects...]
> >
> >On Fri, 10 July 2009 22:40:14 +0200, Bartlomiej Zolnierkiewicz wrote:
> >>
> >> Microsoft having patents on their *obsolete* filesystem should be *their*
> >
> >FAT is far from obsolete.  It is practically always the filesystem of
> >choice and often the only filesystem when trying to move data from one
> >system to another.  The next best alternatives are isofs and ext2.  And
> >I don't know a single digital camera, mp3 player or cellphone that
> >speaks either.
>
> The next best would probably be UDF, which is already used on DVDs
> and thus is implemented in a number of devices - though probably
> only disc-reading ones.
> There's your market hole, dear vendors.

UDF has already been mentioned on this thread, next to "looks usable
in theory, now try it and find out it isn't".

-- 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 Tuesday 2009-07-14 00:20, Jamie Lokier wrote:
>> The next best would probably be UDF, which is already used on DVDs
>> and thus is implemented in a number of devices - though probably
>> only disc-reading ones.
>> There's your market hole, dear vendors.
>
>UDF has already been mentioned on this thread, next to "looks usable
>in theory, now try it and find out it isn't".
>

Sorry if I was showing a lack of enthusiasm discussing, let alone
reading, the legalese subthreads.
Please do not expect everybody to follow LKML as close as akpm/jcm.

The fact that people even dropped the mailing list from Cc on a
subthread effectively rendered my ~/.procmailrc sort-to-folder rules
useless so that I just decided to hit Thread-Delete to get rid of it
from the master INBOX.

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