[PATCH] Added CONFIG_VFAT_FS_DUALNAMES option

Hi Jan,

 > It is much more with devices that are commonly operated with long
 > names - multimedia players come to mind - and these "always"
 > want a valid 8.3.

Would you mind running an experiment for me with your IOneIt MP3
player?

Change vfat_build_dummy_83_buffer() to just do this:

  memset(msdos_name, ' ', 11);

and nothing else. Then delete and re-create the files that you had
problems with and see if your MP3 player is then happy to play
them. That helps a lot with Win98, and I wonder if it also helps with
your IOneIt player.

As I mentioned previously, since your report I'm trying to test on a
bunch of different MP3/media players. So far the tests I've done have
worked fine with the dualnames patch, but I'm still waiting on
delivery of more cheap MP3 players from eBay.

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 and Martin,

As promised, I have continued to investigate what is happening with
Win98, even though I don't think it is a high priority.

I've discovered two things that are interesting:

  1) the 11 spaces varient works pretty nicely with it

  2) the current dualnames patch works nicely if you change the first
  byte to a '~' instead of a space.

What seems to be happening is that Win98 either wants all spaces, or
it wants to see a '~' in the 8 byte prefix, after taking into account
nul termination. If it doesn't see this '~' then it doesn't even look
for a long name.

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

The patch to dosfstools makes it skip the invalid 8.3 entries, just as
windows chkdsk does. The patch is here:

  http://samba.org/tridge/dosfstools.patch1

The patch to mtools is partly cosmetic, and partly to fix a bug in the
VFAT checksum routine. The code in mtools incorrectly treated a nul
byte as special in 8.3 directory entries. The patch is here:

  http://samba.org/tridge/mtools.patch1

 > Thus even when the patch only changes the values stored for new - or
 > rewritten? - files it actively corrupts the meta consistency of the whole
 > filesystem. To me it is like inserting a defective inode into a consistent
 > Linux filesystem.

If the windows implementation is taken as the reference implementation
then the files are not considered defective. The windows chkdsk will
(with a small probability) complain of duplicates, but it doesn't
complain about the entries being defective in any other way.

 > I don't believe that Microsoft is still providing updates for Win98. But I
 > think Windows 2000 might still be in use - I for example have a Win 2000
 > installation on my ThinkPad T23, although I didn't boot it for about a
 > year or so. Has it been tested against Windows 2000? I digged for the mail
 > where you said something about against which Windows versions you tested,
 > but I didn't find it anymore.

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.

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

Can you explain what standard you think should be applied to patent
workaround patches for them to be acceptable? I'd like to know if
there is the possibility of us finding some agreement in the future or
not.

For example, some possibilities might be:

  1) no patent workarounds allowed in upstream kernel at all

  2) the workaround must be shown to have 100% compatibility with all
  current and possible future devices

  3) the workaround must be shown to have a high degree of
  compatibility with all the devices we have available to test with

  4) the workaround must have the highest degree of compatibility that
  we can achieve with the most used devices, but some degree of
  interoperability problems are OK for less used devices.

There are lots of possible levels in between these of course. I don't
think you are advocating (1) or (2), as you seem happier with the "no
long name creation" patch from May.

I also know you want whatever is done to be a different filesystem
name.

I'm advocating (4) as a reasonable standard, although I'd like to
achieve (3) if we can. Whether we can actually achieve (3) will depend
on the results of further testing (see my messages to Jan on that for
example).

I apologise if you don't think this is a reasonable way to phrase the
question. As you are the most vocal opponent of the patch, I'd like to
better understand what it would take for you to find a patch
acceptable.

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/

[OGAWA Hirofumi]

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.

Thanks.
--
OGAWA Hirofumi <hirofumi@...>
--
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]

tridge@... writes:

> Can you explain what standard you think should be applied to patent
> workaround patches for them to be acceptable? I'd like to know if
> there is the possibility of us finding some agreement in the future or
> not.

You are talking different thing than patch. Please stop it.

Thanks.
--
OGAWA Hirofumi <hirofumi@...>
--
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:27:39, OGAWA Hirofumi wrote:
> tridge@... writes:
>
> > Can you explain what standard you think should be applied to patent
> > workaround patches for them to be acceptable? I'd like to know if
> > there is the possibility of us finding some agreement in the future or
> > not.
>
> You are talking different thing than patch. Please stop it.

Uff, the patch is obviously trash -- takes working code, replaces it
with known broken code -- so some justification is neccessary.

Outside of U.S., the patch makes obviously no sense.
                                                                        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/

[David Newall-3]

Pavel Machek wrote:
> On Thu 2009-07-09 14:27:39, OGAWA Hirofumi wrote:
>  
>> You are talking different thing than patch. Please stop it.
>>    
>
> Outside of U.S., the patch makes obviously no sense.

I think it does make sense outside of the USA.  Australia's previous
Prime Minister, Bonsai, signed a free trade agreement with Warmerica and
therefore the patent should be considered an active threat there, too.

While the patch seems too flawed, Andrew's approach, namely looking to
work around the patent, is sound.  In fact it's more than sound, it's a
brilliant attack for the reasons he stated.  Given the negative attitude
displayed towards Andrew's approach, I think it's appropriate for him to
get the policy clarified before he wastes any more of his time on the
technical issues.

I applaud his efforts in this regard.
--
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 Thursday 2009-07-09 04:23, tridge@... wrote:

>
> > It is much more with devices that are commonly operated with long
> > names - multimedia players come to mind - and these "always"
> > want a valid 8.3.
>
>Would you mind running an experiment for me with your IOneIt MP3
>player?
>
>Change vfat_build_dummy_83_buffer() to just do this:
>
>  memset(msdos_name, ' ', 11);
>
>and nothing else. Then delete and re-create the files that you had
>problems with and see if your MP3 player is then happy to play
>them. That helps a lot with Win98, and I wonder if it also helps with
>your IOneIt player.

Nope. It must not be blank.

>As I mentioned previously, since your report I'm trying to test on a
>bunch of different MP3/media players. So far the tests I've done have
>worked fine with the dualnames patch, but I'm still waiting on
>delivery of more cheap MP3 players from eBay.

If I read a review right, the device has also been
distributed under the rebranded name Grundig MPAXX MP 650.
(Other MPxyz numbers are rebrands of other devices.)
The availability of MP650 is similarly low.
--
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]

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

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

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

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

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

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

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

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

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

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

Ok - that is important and I accept that.

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

Agreed

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

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

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

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

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

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

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

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

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

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

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

[Alan Cox]

> Can you explain what standard you think should be applied to patent
> workaround patches for them to be acceptable? I'd like to know if
> there is the possibility of us finding some agreement in the future or
> not.
>
> For example, some possibilities might be:
>
>   1) no patent workarounds allowed in upstream kernel at all

I have no problem with working around alleged patents

>   2) the workaround must be shown to have 100% compatibility with all
>   current and possible future devices

If we have a workaround that is truely compatible with stuff and has no
real impact then I am all for applying it.

>   3) the workaround must be shown to have a high degree of
>   compatibility with all the devices we have available to test with

IFF the workaround can be turned off for non problem parts of the world
IFF we can define what the failure models are

That bit is critical

>   4) the workaround must have the highest degree of compatibility that
>   we can achieve with the most used devices, but some degree of
>   interoperability problems are OK for less used devices.

At this point we get into last resorts. I don't believe unpredictable
interoperability problems are acceptable, especially for file systems.

To give an example of the reverse case, a video decoder for some web
sites that only played most but not all content of that format wouldn't
worry me. Why - because the failure case is defined ("Sorry can't play
that because of patents" dialogue box) and there isn't a real risk of
loss.

> There are lots of possible levels in between these of course. I don't
> think you are advocating (1) or (2), as you seem happier with the "no
> long name creation" patch from May.

I am. For the simple reason that

        cp importantstuff.doc /media/wibble
        umount; eject

go to random other system and access the document has to be a reliable
process and it is far better to get the error copying (and use a
shortname) than to arrive at the other end of an eight hour flight to
find your document is invisible on the recipient system. Hence the focus
on definable the failure case. We wouldn't apply an fs patch that
randomly vanished files from some systems, and you wouldn't apply a SAMBA
patch that made documents vanish from some systems without apparent logic.

> I apologise if you don't think this is a reasonable way to phrase the
> question. As you are the most vocal opponent of the patch, I'd like to
> better understand what it would take for you to find a patch
> acceptable.

I want to find an elegant solution to this, that is reliable, safe for
users and doesn't mislead. If asking multi-choice questions like that
helps keeps going the right way carry on.

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

> And could you please stop talking about other than technical issues? My
> poor brain is already overflowed.

Sorry but the two really do overlap in this case.

> I'm a fool?  Yes, I agree.

You are no fool. I certainly could not hold a debate about patents and
ethics in a second language.

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

[John Lanza]

I apologize to those of you who have already gotten this email.  I am
resending because I just learned the mailing list has been rejecting
my emails beacuse they are in HTML format.

johnl

On Wed, Jul 8, 2009 at 11:14 PM, John Lanza<jdlanza@...> wrote:

> All:
>
> I apologize for the lack of responsiveness on my part over the past couple
> of days.  Although I checked in dutifully over the weekend, most of Monday
> and Tuesday were consumed with a project.
>
> At this point, though, I have reached out to certain members of this
> community and provided at least an initial explanation.  I am willing to do
> the same for anyone interested -- simply reply back to this email and let me
> know of your interest.
>
> johnl
>
> On Tue, Jul 7, 2009 at 7:25 AM, Jamie Lokier <jamie@...> 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...
>>
>> -- 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/

Am Donnerstag 09 Juli 2009 schrieb tridge@...:
> What seems to be happening is that Win98 either wants all spaces, or
       ^^^^^

I can't comment on the technical details, cause I do not know them. But
this again looks to me like playing roulette on compatibility.

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

[James Bottomley-2]

On Thu, 2009-07-09 at 10:42 +0100, Alan Cox wrote:
> > no, when the vendors are given a clearly non-infringing way of
> > implementation then I think they will go for it. The proof is that
>
> Even if they go for the non-infringing tweak they will still end up with
> patches to rip out the potentially infringing code paths.

You keep saying this and I keep pointing out to you it's not true.

Vendors would only rip the code out if they truly feared a suit for
contributory infringement based on shipping the code.  I don't actually
believe that a compile time option they turn on in the binary kernel to
make it non infringing coupled with shipping code where the user could
recompile with it off is sufficient to rise to the tests under the
contributory infringement doctrine.

Even if I'm wrong on this, vendors still won't rip out the code in this
case principally because this is a weak set of patents they universally
regard as invalid.  The way to troll with a weak patent is to go after
the small fish (namely end users) who can't sustain a business shutdown
under TRO or ITU actions.

The point of this patch is to alter the code sufficiently to forestall
troll actions against small redistributors or end users, not to shield
vendors from contributory infringement suits which would never get filed
because the patents are too weak for such a large scale attack.

James


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

> > Even if they go for the non-infringing tweak they will still end up with
> > patches to rip out the potentially infringing code paths.
>
> You keep saying this and I keep pointing out to you it's not true.

You keep saying this is not true and you keep ignoring the fact that a)
it is true and b) you can look at lots of existing RPM packages and see
that today. The evidence is out there - no hearsay, no question marks, go
look.

> contributory infringement based on shipping the code.  I don't actually
> believe that a compile time option they turn on in the binary kernel to
> make it non infringing coupled with shipping code where the user could
> recompile with it off is sufficient to rise to the tests under the
> contributory infringement doctrine.

Its a simple risk test. Anything which reduces risk but does not change
functionality is something you do. Its basically a zero cost way to
reduce the chances of being shot at.

The decision they have to make is full vfat v tridgefat v fat. Once you
make that decision and any part of that decision involves not enabling a
feature because of a theoretical concern about a dubious patent you rip
the code out of your tree as well. So if a vendor picked tridgefat they'd
rip out the source bits outside of the ifdefs that switched tridgefat v
vfat.

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/

[tytso]

On Thu, Jul 09, 2009 at 03:10:09PM +0100, Alan Cox wrote:
> > contributory infringement based on shipping the code.  I don't actually
> > believe that a compile time option they turn on in the binary kernel to
> > make it non infringing coupled with shipping code where the user could
> > recompile with it off is sufficient to rise to the tests under the
> > contributory infringement doctrine.
>
> Its a simple risk test. Anything which reduces risk but does not change
> functionality is something you do. Its basically a zero cost way to
> reduce the chances of being shot at.

Look, even if what you say is valid (despite the advice of lawyers),
it is still useful for us to apply the patch (with the CONFIG option)
in the upstream sources.  It means that support for the workaround
stays in the mainstream sources, so we don't have to worry about
separate patch going no longer applying as time goes by and the
upstream sources change over time.  *If* a vendor really wants to
strip out the source code, they can do that easily enough using
unifdef to strip out the one specific CONFIG option.

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
out (but still present) source code might be considered "contributory
infringment" (and we have legal advice saying that this would not be
the case), either way, the *binary*, which is to say the **product**
does not contain any of the infringing functionality or code.  Hence,
the patent troll won't be able to use an ITC action to stop the
product at the border, thus putting the potentially weak company out
of business.  Suing for contributory infringment takes time;
potentially years, so there is plenty of time for (a) the patent
troll, if it is a company like Microsoft, to suffer all sorts of
public relations damange, thus revealing the claims of people like Sam
Ramji as empty and cynical, and (b) for the community to rally around
said company and provide defense.  In addition, healing a cliam of
contributory infringment is easy enough; simply releasing a version of
the source code with unifdef applied won't changing the resulting
binary.  

In any case, the fact that the patent troll won't be able to put a
company out of business, but instead might have to wage a long legal
war (consider how long the SCO lawsuits have dragged on), will tend to
dissuade the rational troll from pursuing such a path; and even if we
do have an irrational actor, (a) I don't really think Microsoft is
irrational, and (b) in the U.S. you can get a lawyer to sue a ham
sandwich, so there's no real proactive steps you can take to protect
yourself against an irrational actor who is bound and determined to
abuse the legal system; and most companies and lawyers (as opposed to
people who like to play lawyers on mailing lists and TV) understand
that.

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

Regards,

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

[Christoph Hellwig]

On Thu, Jul 09, 2009 at 11:25:41AM -0400, Theodore Tso wrote:
> Look, even if what you say is valid (despite the advice of lawyers),
> it is still useful for us to apply the patch (with the CONFIG option)
> in the upstream sources.  It means that support for the workaround
> stays in the mainstream sources, so we don't have to worry about
> separate patch going no longer applying as time goes by and the
> upstream sources change over time.  *If* a vendor really wants to
> strip out the source code, they can do that easily enough using
> unifdef to strip out the one specific CONFIG option.

By putting it in the kernel tree we would only give the bogus patent
claims more credit.  And so far no one has but IBM has actually care
about the patch.  Tridge can put the patch into the IBM kernel tree for
the service processors if you really deeply care, but can we leave the
rest of the world alone?

If someone really wants a patch to corrupt their filesystems they know
where to find it.
--
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/

Am Donnerstag 09 Juli 2009 schrieb tridge@...:
> Hi Martin,

Hi Tridge,

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

There might be some stuff laying around on some magazine CD/DVDs, but
honestly I lack the motivation to do any testing. I am still not a fan of
your patch. And I think the people that are interested in getting the
patch in should do the testing - not me. Why should I do the work that
TomTom and other companies not willing or able to fight patents legally
might be interested in getting done? A motivation would be to think that
it actually helps towards a software patent free world, but I am not
convinced that it does.

>  > 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.
>
> The patch to dosfstools makes it skip the invalid 8.3 entries, just as
> windows chkdsk does. The patch is here:
>
>   http://samba.org/tridge/dosfstools.patch1
>
> The patch to mtools is partly cosmetic, and partly to fix a bug in the
> VFAT checksum routine. The code in mtools incorrectly treated a nul
> byte as special in 8.3 directory entries. The patch is here:
>
>   http://samba.org/tridge/mtools.patch1

Okay. But then before activating the your Linux kernel patch as default
there should a transition time to let distro pick up the newest stuff and
a safety margin for users to upgrade to them. If it should be activated as
default at all.

>  > Thus even when the patch only changes the values stored for new - or
>  > rewritten? - files it actively corrupts the meta consistency of the
>  > whole filesystem. To me it is like inserting a defective inode into
>  > a consistent Linux filesystem.

> If the windows implementation is taken as the reference implementation
> then the files are not considered defective. The windows chkdsk will
> (with a small probability) complain of duplicates, but it doesn't
> complain about the entries being defective in any other way.

But you and others consider the characters / bytes your patch put into the
short names as invalid. How did you come to that conclusion? Either these
characters are invalid or they are not. An indication would be on what DOS
would allow me to create. Does it allow me to create files with those
characters such as blanks or null bytes with simple DOS commands. If not,
then not checking filenames in short name FAT for invalid names seems to
be an omission in CHKDSK for me.

Even when fsck.{ext3,whatever}/xfs_check/xfs_repair doesn't moan about "/"
in filenames I would still consider them invalid and think any software
which creates those actively corrupts an Ext3, XFS, whatever unix
filesystem.

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

[David Newall-3]

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