|
tridge offers a new patch to Linux's VFAT filesystem |
|
Sunday, June 28 2009 @ 11:59 PM EDT
|
tridge has done it again, offering a patch to Linux's VFAT filesystem that
retains support for long names, while carefully avoiding
ever having both a long and a short name for the same
file. As before, media containing the old long/short-name
combination VFAT format are still supported. His comment on LKML:
Date Sat, 27 Jun 2009 05:19:33 +1000
Subject [PATCH] Added CONFIG_VFAT_FS_ DUALNAMES option
From tridge@samba ...
This is a new patch for VFAT long filename support, replacing the one
that I posted last month. It retains a lot more functionality then the
previous patch.
A FAQ will be posted immediately after this patch to answer the
questions that were raised from the previous discussion.
Cheers, Tridge And here is the FAQ. Note particularly what can and can't be safely discussed regarding patents on LKML. Here's
the prior patch, for completeness.
To make sure we are all up to speed, let's look at the entirety of the FAQ:
Date Sat, 27 Jun 2009 05:22:54 +1000
Subject FAQ on 2nd VFAT patch
From tridge@samba ...
Following the feedback from the first patch, we have put together a
short FAQ that tries to address the kinds of questions that were
raised during that discussion. The Linux Foundation has organized for
a patent attorney, John Lanza, to be available to answer legal
questions that come up, to the extent that he is able to. John is CCd
on this email.
Cheers, Tridge
------
Q1. Has this patch undergone legal review?
A1. Both the original patch and the new patch that we posted today
have been through legal review by several lawyers who specialize
in this area. We can't post all of the details of those reviews,
but John Lanza is CCd on this email, and hopefully he will be
able to answer any questions that arise or if he can't answer
some question he may be able to explain why he can't answer
it. John is a patent attorney who represents the Linux
Foundation.
Q2. What can we safely post on LKML about patent infringement?
A2. Almost nothing. Even a statement of the form "If A were the case,
then B would result in infringement of patent C" is extremely
dangerous. It allows a patent attorney to argue that truth or
falsity of A is a legal question of fact, even if A is an obvious
technical fallacy (remember that the patent holder can call on
its own expert witnesses). The existence of a legal question of
fact can be used to defeat a pre-trial summary judgment motion
for noninfringement and dismissal of the lawsuit. The defeat of
pre-trial summary judgment motions results in the suit going to
trial, which is always quite expensive. The patent holder can be
expected to choose a target that cannot afford a trial, resulting
in a settlement or capitulation. The patent holder can then use
the fact that target #1 settled to apply more pressure on targets
#2, #3, and so on.
This can happen even if you later clearly state that A is an
obvious technical fallacy. The patent holder would just say
something like, "Your Honor, J. Random Hacker admitted that B is
the case, and we will prove that he was mistaken when he later
retracted that admission and tried to claim that A was an obvious
technical fallacy. We will demonstrate, by Mr. Hacker's own
words, that our valuable patent C is in fact infringed." The
patent holder might well lose that point later at trial, but only
if the target can afford to go to trial in the first place.
In short, anything posted on LKML is on the public record and can
therefore be read and archived and used by patent holders to
convince a judge to dismiss summary judgment motions in order to
threaten a costly trial and try to force a settlement.
Q3. Why should we apply a patch to avoid a patent that might be invalid?
A3. It takes a lot of time in the courts (and thus, a lot of money)
to legally prove that a patent is invalid, and in the meantime
the patent remains at least a nuisance and in practice still
dangerous. Any damage done during this time period, to both
persons and organizations, might well be permanent -- it might
never be possible to repair that damage, even if the patent
should eventually be invalidated. On the other hand, a patch
that avoids both the patent and regressions in function and
performance can greatly reduce the danger of such damage.
One of the specific dangers that needs to be addressed is
illustrated by the ITC action that Microsoft took against TomTom:
http://www.itcblog.com/20090227/
microsoft-files-new-337-complaint-against-tomtom-regarding-
certain-portable-navigation-devices/
That ITC action asked for TomTom's products to be seized at US
borders, and might have effectively shutdown TomTom as a going
concern in the US. If Microsoft did the same thing to another
Linux vendor then even though the vendor might eventually win
they could still be severely damaged just by having their market
disrupted or frightened.
The way to avoid this is to ensure that the Linux kernel is so
obviously non-infringing that the case does not even go to trial.
That means you have to have an extremely clear explanation of how
the patent does not apply to your code. The aim of the patches we
have posted is to ensure that we would meet that standard.
Q4. Suppose we accept such a patch. How do we deal with the
possibility that future bug fixes undo the patch?
A4. This is a very real concern. In this case, I hope that the
explanation below provides Hirofumi-san the information needed to
avoid this possibility. If some future patch looks to him like
it might re-introduce the problem, he could check with one of the
people who submitted this patch.
This is similar to what a subsystem maintainer does when they
check with the owner of some exotic piece of hardware whether a
proposed patch would break the kernel on that hardware.
Q5. Why do you believe that this patch avoids the patent?
A5. It is not appropriate for us to provide the full details of the
legal reasoning on a public forum, but we can sketch out some
facts here which may be helpful. Then if you have any more
specific questions you can direct them to John Lanza. You should
note that this sketch is not a legal opinion, because legal
opinions are given to direct clients, not to a public forum like
lkml.
The claims of both of the VFAT patents "create" or "store" a long
filename entry. The first patch we posted changed the code so
that long filename entries are never created or stored. That
patch left unchanged the code for reading long filename entries,
and so the patch kept the functionality of reading existing long
filenames. The result is a patch that loses some functionality
(creating or storing long filenames), but did no creating or
storing of long filenames.
The 2nd patch we just posted takes a different approach. The
claims of both of the VFAT patents involve the creation (or
storing) of both a long filename and a short filename for a file.
The 2nd patch only creates/stores either a short filename or a
long filename for a file, but never both. The 11 bytes created by
vfat_build_dummy_83_buffer() to pad the field for short filenames
cannot be used to access the file, and contain bytes which are
invalid in FAT and VFAT filenames, and therefore are not
filenames as that term is and has been used in the technical
community.
Q6. Why the random values for the field in which the short filename
would normally be stored?
A6. The patch includes some comments that explain why we chose those
particular byte values. Basically we needed to minimise the
chance of triggering a bug in WindowsXP where some values would
cause XP to crash with a blue screen (Vista and Windows7 do not
seem to have this bug). The values were also chosen to have a
quite low chance of causing any problems with chkdsk.exe on
Windows.
Q7. What if I need to access the files with an old version of DOS
or Windows that does not understand long filenames?
A7. In this case, you can use the msdos filesystem to enforce 8.3
format names. We believe that these old versions are
sufficiently rare that this is not a real concern.
Q8. The first patch was configured off by default, while this patch
is configured on by default. Why the difference in behavior?
A8. The first patch disabled significant function, while this new
patch allows all the filenames allowed by the VFAT format. If
accepted, it is of course up to the maintainers to decide what
the default should be in mainline, or even if the patch should be
unconditional. We are happy with any of these three choices
(configurable default disabled, configurable default enabled, or
unconditionally disabled).
There is an ancient saying that when a wise man sees trouble ahead, he avoids it, but a fool walks right into it. The community sees trouble ahead, so it makes good sense to avoid it.
|
|
Authored by: LocoYokel on Monday, June 29 2009 @ 12:11 AM EDT |
Please title Error -> Correction with details in body. [ Reply to This | # ]
|
|
Authored by: LocoYokel on Monday, June 29 2009 @ 12:11 AM EDT |
Please indicate which news pick you are discussing in title. [ Reply to This | # ]
|
|
Authored by: LocoYokel on Monday, June 29 2009 @ 12:13 AM EDT |
Please follow the posting guidelines and make links clicky as shown in the red
text below the text window.[ Reply to This | # ]
|
- ... "when a wise man sees trouble ahead, he avoids it, but a fool walks right into it" - Authored by: Anonymous on Monday, June 29 2009 @ 03:15 AM EDT
- Method and apparatus for changing software components in an information handling system - Authored by: Anonymous on Monday, June 29 2009 @ 09:27 AM EDT
- MP3s require a license from Sony - Authored by: emacsuser on Monday, June 29 2009 @ 09:56 AM EDT
- The Restoration of Early UNIX Artifacts - Authored by: JamesK on Monday, June 29 2009 @ 11:02 AM EDT
- America's Fortress: Cheyenne Mountain, NORAD live on - Authored by: tiger99 on Monday, June 29 2009 @ 12:42 PM EDT
- Stargate - Authored by: argee on Tuesday, June 30 2009 @ 02:10 AM EDT
- Fraudster Madoff gets 150 years - Authored by: tiger99 on Monday, June 29 2009 @ 12:56 PM EDT
- We Should Have Embraced Napster - Authored by: Anonymous on Monday, June 29 2009 @ 08:09 PM EDT
- Google Makes a Case That It Isn’t So Big - Authored by: Gringo on Tuesday, June 30 2009 @ 12:35 AM EDT
- SCOGBK-820, Berger-Singerman expences for May - Authored by: Anonymous on Tuesday, June 30 2009 @ 01:03 AM EDT
- ©: Of Catty Rants and Copyrights - Authored by: Anonymous on Tuesday, June 30 2009 @ 02:11 AM EDT
- There's something missing in my life. - Authored by: Ian Al on Tuesday, June 30 2009 @ 04:31 AM EDT
- Litter louts shown on website - Authored by: Nick_UK on Tuesday, June 30 2009 @ 06:13 AM EDT
- The Pirate Bay to be sold - Authored by: Anonymous on Tuesday, June 30 2009 @ 06:54 AM EDT
- "The Judiciary" - Authored by: Anonymous on Tuesday, June 30 2009 @ 01:57 PM EDT
- "The Judiciary" - Authored by: Anonymous on Tuesday, June 30 2009 @ 02:30 PM EDT
- The judge - Authored by: Anonymous on Tuesday, June 30 2009 @ 07:44 PM EDT
|
Authored by: Anonymous on Monday, June 29 2009 @ 01:18 AM EDT |
Microsoft's corporate culture has always been based in subversion &
intimidation, so the result is this kind of "we can't discuss it or we
might get sued" kind of defensiveness.
It is quite obvious in practice that Microsoft's promises not to sue etc. are
not at all believed by those who are in a position to decide what matters in
this regard.
I'll say further, on the behalf of many, that the current SCO shenanigans and
its new sources of funding are known to be a direct result of Microsoft
laundering its influence in order to appear uninvolved.
Microsoft, we know you, we know your lying, thieving, conniving ways, and we
know for sure that you will get what is coming to you in ways that are
definitely not in your gamebook. No action is requires at this point - only
simple clear-eyed unblinking awareness is all that is necessary ...
</rant>
[ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, June 29 2009 @ 01:39 AM EDT |
A brilliant man and a hacker after my own heart. He has done so much above and
beyond just the reverse engineering of the Microsoft SMB protocols and creation
of Samba (no small feat in itself). I think of him every time I download a
video from my (hacked) TiVO to my computer.
JSL[ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, June 29 2009 @ 02:47 AM EDT |
The defeat of pre-trial summary judgment motions results in the suit going
to trial, which is always quite expensive. The patent holder can be expected to
choose a target that cannot afford a trial, resulting in a settlement or
capitulation.
I think these two sentences adequately rebut anyone who
claims that there is any good in the US legal system.
[ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, June 29 2009 @ 02:55 AM EDT |
Huge amounts of wasted effort, all caused by a combination of insane patent law,
incompetent courts, and terrorist corporations.
The US legal system is totally broken.
[ Reply to This | # ]
|
- EGAD! - Authored by: stegu on Monday, June 29 2009 @ 05:49 AM EDT
- EGAD! - Authored by: Anonymous on Monday, June 29 2009 @ 05:59 AM EDT
- EGAD! - Authored by: stegu on Monday, June 29 2009 @ 06:23 AM EDT
- EGAD! - Authored by: mpellatt on Monday, June 29 2009 @ 06:43 AM EDT
- EGAD! - Authored by: Wol on Monday, June 29 2009 @ 08:46 AM EDT
- EGAD! - Authored by: hutcheson on Monday, June 29 2009 @ 10:16 AM EDT
- Illness - Authored by: Anonymous on Monday, June 29 2009 @ 10:41 AM EDT
- Bad example - Authored by: Mikkel on Monday, June 29 2009 @ 07:13 PM EDT
- EGAD! - Authored by: LaurenceTux on Tuesday, June 30 2009 @ 10:25 AM EDT
- EGAD! - Authored by: JamesK on Monday, June 29 2009 @ 07:46 AM EDT
- EGAD! - Authored by: stegu on Monday, June 29 2009 @ 09:17 AM EDT
- EGAD! - Authored by: Tyro on Monday, June 29 2009 @ 12:45 PM EDT
- EGAD! - Authored by: stegu on Tuesday, June 30 2009 @ 05:37 AM EDT
|
Authored by: Anonymous on Monday, June 29 2009 @ 03:07 AM EDT |
> It allows a patent attorney to argue that truth or falsity of A is a
> legal question of fact, even if A is an obvious technical fallacy
[ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, June 29 2009 @ 07:20 AM EDT |
"Both the original patch and the new patch that we posted today have been
through legal review by several lawyers who specialize in this area."
So this is what we've come to. The predictions have come true. You now need to
hire a team of lawyers to review any code you write.
Sign me,
Applying for a fast food preparation job.[ Reply to This | # ]
|
|
Authored by: grouch on Monday, June 29 2009 @ 09:55 AM EDT |
A6. The patch includes some comments that explain why we chose
those particular byte values. Basically we needed to minimise the chance of
triggering a bug in WindowsXP where some values would cause XP to crash with
a blue screen (Vista and Windows7 do not seem to have this bug). The values
were also chosen to have a quite low chance of causing any problems with
chkdsk.exe on Windows.
[Bold added].
Just think of all
those gubmint computers (your tax dollars at work) which can still be
crashed with a file name . "Enterprise ready" indeed. Now how
much would you pay for this and all the other wondrous features of
Microsoft?
I wonder how many patents in Microsoft's portfolio cover the many
ways to accomplish the Blue Screen Of Death.
--- -- grouch
GNU/Linux obeys you.
[ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, June 29 2009 @ 01:51 PM EDT |
I applaud them for doing what is necessary to help keep Linux distributors,
contributors and users safe from this particular, single threat.
At the same time, I deplore the state of a legal system that has allowed these
patents *and many thousands of others of similarly dubious merit* to hinder
innovation and competition for many years.[ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, June 29 2009 @ 04:20 PM EDT |
The values were also chosen to have a quite low chance of causing any
problems with chkdsk.exe on Windows.
I'll bet you $100 that a
future release of chkdsk.exe will have problems.
There is a good
chance that, within Microsoft, the message has already been passed to the team
that is responsible for chkdsk.exe: "The job's not done until chkdsk won't
run on filesystems using Tridge's patch." [ Reply to This | # ]
|
- BIG mistake? - Authored by: Anonymous on Tuesday, June 30 2009 @ 01:05 AM EDT
- BIG mistake? - Authored by: Anonymous on Tuesday, June 30 2009 @ 02:51 PM EDT
|
Authored by: sproggit on Monday, June 29 2009 @ 06:11 PM EDT |
Make no mistake, this is an amazing piece of work by Tridge, and it just goes to
show the creativity of the Human Spirit in the face of adversity.
But whilst I can applaud this achievement, I cannot escape from the feeling that
hidden within this triumph of a patch, there lies a disaster of an ambush,
waiting to happen.
It goes like this.
First, Microsoft and others spend tens of millions of dollars with the USPTO to
register a raft of software patent claims. So the law on whether or not software
patents are valid is a bit woolly. So what? Here's this huge and wealthy company
willing to pump millions of dollars into the Federal Purse. OK, then. Go right
ahead.
And so like the shot of morphine that kills an addict, the money flows in.
But voices speak out. The thing is, those voices vary by degrees. Some argue
that *all* software patents are invalid and must be stopped. Other are willing
to concede that the patent process could be applied to software, providing the
original doctrine of the patent [ "Non obvious to a practitioner skilled in
the art..." ] is maintained and enforced.
Back to the earlier analogy, it's like arguing that a little bit of morphine is
OK. Maybe it is. But there's no such thing as "a little bit" when the
dispenser is the patient and there is no safety in place.
Then we have another group [ and with the most profound and humble respect to
Andrew and his good work, exemplified here ] this example may fall into this
category. There is now a tacit acknowledgement that well, shucks, software
patents may well be the law, so we'll have to live with that, but hey, look,
here's a way that we can wriggle past this patent and still make our code work.
I'm absolutely not a lawyer and therefore should largely be ignored on anything
vaguely legalistic. But I want to think about what is right and what is wrong.
Surely, taking this fork, going down this road can only be wrong.
Those who wish to constrain and extinguish the threat of Free Software are not
going to stop, satisfied that this one file system patent is not infringed.
There will be another, and another, and a third. By the time that we get to the
three-hundred-and-thirty-third, the FOSS community will spend more time dodging
patents than innovating. The proprietary, pro-software patent camp will stand
back with crocodile tears... "Well, there free to sign a cross-patent
license with us, except, of course, they don't have anything patented that we
want. Too bad. Or they could purchase a license, though not one that would
enable this unique IP to be included in open-sourced code. Too bad.
And so it goes.
And the answer? Well, I'd say that's not entirely clear. I reckon the best we
can hope for is that companies outside the US will realise that if they embrace
FOSS, they actually have a chance to grow strong, vibrant and healthy software
industries of their own. Their need to purchase software licenses from US
companies will drop away, and their own economies will benefit from the
innovation.
This is great work tridge, a compliment offered with sincerity, humility and
respect.
But what's the next step? Or the next? Or the one after that? [ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, June 29 2009 @ 08:24 PM EDT |
"A8. The first patch disabled significant function, while this new patch
allows all the filenames allowed by the VFAT format. If accepted, it is of
course up to the maintainers to decide what the default should be in mainline,
or even if the patch should be unconditional. We are happy with any of these
three choices (configurable default disabled, configurable default enabled, or
unconditionally disabled)."
I'm puzzled why the "unconditionally disabled" option is endorsed,
while the converse (unconditionally enabled) is not even mentioned?
Also, if someone wants to include this patch, and his/her distro unconditionally
disables this option, what's s/he to do, short of downloading the kernel and
re-compiling it from scratch? By the way, this has to assume that the
maintainers referred to are distro maintainers, not kernel maintainers; in the
latter case, the point is totally moot, anyway.[ Reply to This | # ]
|
|
Authored by: SpaceLifeForm on Monday, June 29 2009 @ 08:48 PM EDT |
Yet.
---
You are being MICROattacked, from various angles, in a SOFT manner.[ Reply to This | # ]
|
|
Authored by: davecb on Tuesday, June 30 2009 @ 11:14 AM EDT |
In Tridge's FAQ, he cautions the actual developers from speculating on the
sufficiency of the patch. However, people who aren't Linux core developers can
post to the list, and other non-developers have commented here and at LWN
about
the issue.
Do only code contributors need to be careful? If not,
anyone, including an employee of the company which owns the patent, could post
speculations to the LKML and put us all at risk...
--dave
--- davecb@spamcop.net [ Reply to This | # ]
|
|
Authored by: Anonymous on Tuesday, June 30 2009 @ 03:58 PM EDT |
Doesn't the mere fact of the patch constitute an admission that the prior code
was infringing upon a (probably invalid) patent? One of the things I hate most
about patents is that they're so filled with catch-22s, where they punish people
for trying to be honest.
Probably explains why patent trolls are so successful, though.[ Reply to This | # ]
|
|
|
|
|