[PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Dave Kleikamp]

From: Andrew Tridgell <tridge@samba.org>
Subject: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

When this option is enabled the VFAT filesystem 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@samba.org>
Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
Acked-by: Steve French <sfrench@us.ibm.com>
Cc: Ogawa Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: Mingming Cao <cmm@us.ibm.com>
---
 fs/fat/Kconfig      |   18 ++++++++++++++++++
 fs/fat/namei_vfat.c |   26 +++++++++++++++++++++-----
 2 files changed, 39 insertions(+), 5 deletions(-)

diff --git a/fs/fat/Kconfig b/fs/fat/Kconfig
index 182f9ff..1439681 100644
--- a/fs/fat/Kconfig
+++ b/fs/fat/Kconfig
@@ -98,3 +98,21 @@ 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.
+
+	  Case on files is only preserved if all of the prefix is the same
+	  case and all of the extension is the same case. So the names
+	  "FILE.txt", "file.TXT" would be case preserved, but if you create a
+	  file called "File.TxT" then it will be stored on disk as "FILE.TXT".
+
+	  Reading files with long file names is still permitted.
diff --git a/fs/fat/namei_vfat.c b/fs/fat/namei_vfat.c
index a0e00e3..cf0400e 100644
--- a/fs/fat/namei_vfat.c
+++ b/fs/fat/namei_vfat.c
@@ -316,6 +316,7 @@ static int vfat_create_shortname(struct inode *dir, struct nls_table *nls,
 	int sz = 0, extlen, baselen, i, numtail_baselen, numtail2_baselen;
 	int is_shortname;
 	struct shortname_info base_info, ext_info;
+	unsigned shortname_flags = opts->shortname;
 
 	is_shortname = 1;
 	INIT_SHORTNAME_INFO(&base_info);
@@ -424,13 +425,20 @@ static int vfat_create_shortname(struct inode *dir, struct nls_table *nls,
 	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;
+	shortname_flags = 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 (shortname_flags & VFAT_SFN_CREATE_WIN95) {
 			return (base_info.upper && ext_info.upper);
-		} else if (opts->shortname & VFAT_SFN_CREATE_WINNT) {
+		} else if (shortname_flags & 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 +601,19 @@ static int vfat_build_slots(struct inode *dir, const unsigned char *name,
 {
 	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
+	unsigned char cksum;
+	int i;
 	loff_t offset;
+	struct msdos_dir_slot *ps;
+#endif
 
 	*nr_slots = 0;
 
@@ -628,6 +640,9 @@ static int vfat_build_slots(struct inode *dir, const unsigned char *name,
 		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 +660,7 @@ static int vfat_build_slots(struct inode *dir, const unsigned char *name,
 	}
 	slots[0].id |= 0x40;
 	de = (struct msdos_dir_entry *)ps;
+#endif
 
 shortname:
 	/* build the entry of 8.3 alias name */

-- 
David Kleikamp
IBM Linux Technology Center

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Christoph Hellwig]

On Fri, May 01, 2009 at 12:41:29PM -0500, Dave Kleikamp wrote:
> From: Andrew Tridgell <tridge@samba.org>
> Subject: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option
> 
> When this option is enabled the VFAT filesystem 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.

This doesn't make any sense as a compile time option. Might make sense
as a mount option, but I'd like to hear a rationale for it first.

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Dave Kleikamp]

On Fri, 2009-05-01 at 13:47 -0400, Christoph Hellwig wrote:
> On Fri, May 01, 2009 at 12:41:29PM -0500, Dave Kleikamp wrote:
> > From: Andrew Tridgell <tridge@samba.org>
> > Subject: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option
> > 
> > When this option is enabled the VFAT filesystem 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.
> 
> This doesn't make any sense as a compile time option. Might make sense
> as a mount option, but I'd like to hear a rationale for it first.

Some linux-based devices would be happy not to contain code to create
the long name at all.

Thanks,
Shaggy
-- 
David Kleikamp
IBM Linux Technology Center

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Michael Tokarev]

Dave Kleikamp wrote:
> On Fri, 2009-05-01 at 13:47 -0400, Christoph Hellwig wrote:
>> On Fri, May 01, 2009 at 12:41:29PM -0500, Dave Kleikamp wrote:
>>> From: Andrew Tridgell <tridge@samba.org>
>>> Subject: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option
>>>
>>> When this option is enabled the VFAT filesystem 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.
>> This doesn't make any sense as a compile time option. Might make sense
>> as a mount option, but I'd like to hear a rationale for it first.
> 
> Some linux-based devices would be happy not to contain code to create
> the long name at all.

Well, is that a rationale per se?  Which devices they are and why?

But besides, why `msdos' filesystem is not sufficient?
It contains no code to create long file names and no code to
read such names either.

/mjt

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Christoph Hellwig]

On Fri, May 01, 2009 at 01:12:42PM -0500, Dave Kleikamp wrote:
> Some linux-based devices would be happy not to contain code to create
> the long name at all.

Then patch it out.

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Dave Kleikamp]

On Fri, 2009-05-01 at 22:19 +0400, Michael Tokarev wrote:
> Dave Kleikamp wrote:
> > On Fri, 2009-05-01 at 13:47 -0400, Christoph Hellwig wrote:
> >> On Fri, May 01, 2009 at 12:41:29PM -0500, Dave Kleikamp wrote:
> >>> From: Andrew Tridgell <tridge@samba.org>
> >>> Subject: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option
> >>>
> >>> When this option is enabled the VFAT filesystem 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.
> >> This doesn't make any sense as a compile time option. Might make sense
> >> as a mount option, but I'd like to hear a rationale for it first.
> > 
> > Some linux-based devices would be happy not to contain code to create
> > the long name at all.
> 
> Well, is that a rationale per se?  Which devices they are and why?

Could be anything.  cameras, phones, etc.  Anything that might be
mountable by a host computer in order to share files, or to write to a
device that can be shared by other computers or devices.

> But besides, why `msdos' filesystem is not sufficient?
> It contains no code to create long file names and no code to
> read such names either.

An example, an mp3 player wants to read files with long mixed-case
names, which can be manipulated on a host computer.  But it may not need
to create files that don't fit the 8.3 syntax.

Of course, msdos might be a good option for other devices.

Shaggy
-- 
David Kleikamp
IBM Linux Technology Center

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[OGAWA Hirofumi]

Dave Kleikamp <shaggy@linux.vnet.ibm.com> writes:

> Subject: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option
>
> When this option is enabled the VFAT filesystem 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.

I'll answer to only technical part. This patch creates different name
internally, without renaming dcache. Are you really sure if that's ok?

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[OGAWA Hirofumi]

OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:

> Dave Kleikamp <shaggy@linux.vnet.ibm.com> writes:
>
>> Subject: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option
>>
>> When this option is enabled the VFAT filesystem 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.
>
> I'll answer to only technical part. This patch creates different name
> internally, without renaming dcache. Are you really sure if that's ok?

Ah, sorry. I'm missing (is_shortname == 0) part.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[tridge]

OGAWA Hirofumi writes:
 > I'll answer to only technical part. This patch creates different name
 > internally, without renaming dcache. Are you really sure if that's ok?

The name handling should be the same as the existing code path where
goto shortname is done after vfat_create_shortname() in
vfat_build_slots() (ie. when the name conformed to 8.3).

What situation are you thinking of which this would cause a problem?

Cheers, Tridge

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[OGAWA Hirofumi]

OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:

> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:
>
>> Dave Kleikamp <shaggy@linux.vnet.ibm.com> writes:
>>
>>> Subject: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option
>>>
>>> When this option is enabled the VFAT filesystem 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.
>>
>> I'll answer to only technical part. This patch creates different name
>> internally, without renaming dcache. Are you really sure if that's ok?
>
> Ah, sorry. I'm missing (is_shortname == 0) part.

Um.., probably, this patch would be handle the invalid chars for 8.3 alias.
Otherwise, it'll try to create ~<num> postfix, and I guess it'll become
the dcache problem.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[OGAWA Hirofumi]

tridge@samba.org writes:

> OGAWA Hirofumi writes:
>  > I'll answer to only technical part. This patch creates different name
>  > internally, without renaming dcache. Are you really sure if that's ok?
>
> The name handling should be the same as the existing code path where
> goto shortname is done after vfat_create_shortname() in
> vfat_build_slots() (ie. when the name conformed to 8.3).
>
> What situation are you thinking of which this would cause a problem?

At this answer, I was missing the (is_shortname == 0).

However, if filename contains the chars in vfat_replace_char(). It will
have similar problem. In this case, this patch creates the dir entry
without longname. So, it wouldn't match to dcache and real dir entries.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[tridge]

OGAWA Hirofumi writes:
 > Um.., probably, this patch would be handle the invalid chars for 8.3 alias.
 > Otherwise, it'll try to create ~<num> postfix, and I guess it'll become
 > the dcache problem.

Do you think that will cause problems? 

If it will, then we could add something like this after the
vfat_create_shortname() call:

	if (strncasecmp(name, msdos_name, MSDOS_NAME) != 0) {
		err = -EINVAL;
		goto out_free;
	}

or would the potential case change still be a problem?

Cheers, Tridge

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[OGAWA Hirofumi]

tridge@samba.org writes:

> OGAWA Hirofumi writes:
>  > Um.., probably, this patch would be handle the invalid chars for 8.3 alias.
>  > Otherwise, it'll try to create ~<num> postfix, and I guess it'll become
>  > the dcache problem.
>
> Do you think that will cause problems? 

Yes. E.g. "test=.txt" will replace with "test_.txt" or such. But, dcache
still has "test=.txt". It means "test=.txt" would disappear with memory
pressure.

> If it will, then we could add something like this after the
> vfat_create_shortname() call:
>
> 	if (strncasecmp(name, msdos_name, MSDOS_NAME) != 0) {
> 		err = -EINVAL;
> 		goto out_free;
> 	}
>
> or would the potential case change still be a problem?

It may be ok. However, of course, it should consider other than
ascii. Well, I think the patch should be allow only perfect 8.3 name in
vfat_create_shortname(). (i.e. is_shortname && base/ext_info.valid)

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[tridge]

Hi Hirofumi-san,

 > It may be ok. However, of course, it should consider other than
 > ascii. Well, I think the patch should be allow only perfect 8.3 name in
 > vfat_create_shortname(). (i.e. is_shortname && base/ext_info.valid)

ok, so something like this in vfat_create_shortname() ?

#ifdef CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES
	if (is_shortname == 0 ||
	    !(base_info.valid && ext_info.valid))
		return -ENAMETOOLONG;
	shortname_flags = VFAT_SFN_CREATE_WINNT;
#endif

that still means that creating a file ShortNam.TxT actually creates
shortnam.txt on disk. Will the case-insensitive vfat_cmpi used as
d_compare cope OK with that?

Cheers, Tridge

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[OGAWA Hirofumi]

tridge@samba.org writes:

> Hi Hirofumi-san,
>
>  > It may be ok. However, of course, it should consider other than
>  > ascii. Well, I think the patch should be allow only perfect 8.3 name in
>  > vfat_create_shortname(). (i.e. is_shortname && base/ext_info.valid)
>
> ok, so something like this in vfat_create_shortname() ?
>
> #ifdef CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES
> 	if (is_shortname == 0 ||
> 	    !(base_info.valid && ext_info.valid))
> 		return -ENAMETOOLONG;
> 	shortname_flags = VFAT_SFN_CREATE_WINNT;
> #endif

Yes. I guess -ENAMETOOLONG would not good for !valid, and !(is_shortname
&& base_info.valid && ext_info.valid) or add "else" part is more prefer
though.

> that still means that creating a file ShortNam.TxT actually creates
> shortnam.txt on disk. Will the case-insensitive vfat_cmpi used as
> d_compare cope OK with that?

Yes. The case-insensitive is ok, the dcache can handle case-insensitive.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[tridge]

Hi Hirofumi-san,

 > Yes. I guess -ENAMETOOLONG would not good for !valid, and !(is_shortname
 > && base_info.valid && ext_info.valid) or add "else" part is more prefer
 > though.

ok, new patch below. 

 > Yes. The case-insensitive is ok, the dcache can handle case-insensitive.

good, that makes life simpler :-)

Are you happy with the shortname_flags hackery in
vfat_create_shortname() ?

Cheers, Tridge


Signed-off-by: Andrew Tridgell <tridge@samba.org>
diff --git a/fs/fat/Kconfig b/fs/fat/Kconfig
index 182f9ff..66623d0 100644
--- a/fs/fat/Kconfig
+++ b/fs/fat/Kconfig
@@ -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 --git a/fs/fat/namei_vfat.c b/fs/fat/namei_vfat.c
index a0e00e3..4169ec7 100644
--- a/fs/fat/namei_vfat.c
+++ b/fs/fat/namei_vfat.c
@@ -316,6 +316,7 @@ static int vfat_create_shortname(struct inode *dir, struct nls_table *nls,
 	int sz = 0, extlen, baselen, i, numtail_baselen, numtail2_baselen;
 	int is_shortname;
 	struct shortname_info base_info, ext_info;
+	unsigned shortname_flags = opts->shortname;
 
 	is_shortname = 1;
 	INIT_SHORTNAME_INFO(&base_info);
@@ -424,13 +425,22 @@ static int vfat_create_shortname(struct inode *dir, struct nls_table *nls,
 	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;
+	shortname_flags = 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 (shortname_flags & VFAT_SFN_CREATE_WIN95) {
 			return (base_info.upper && ext_info.upper);
-		} else if (opts->shortname & VFAT_SFN_CREATE_WINNT) {
+		} else if (shortname_flags & VFAT_SFN_CREATE_WINNT) {
 			if ((base_info.upper || base_info.lower) &&
 			    (ext_info.upper || ext_info.lower)) {
 				if (!base_info.upper && base_info.lower)
@@ -628,6 +638,9 @@ static int vfat_build_slots(struct inode *dir, const unsigned char *name,
 		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 +658,7 @@ static int vfat_build_slots(struct inode *dir, const unsigned char *name,
 	}
 	slots[0].id |= 0x40;
 	de = (struct msdos_dir_entry *)ps;
+#endif
 
 shortname:
 	/* build the entry of 8.3 alias name */

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[OGAWA Hirofumi]

tridge@samba.org writes:

>  > Yes. I guess -ENAMETOOLONG would not good for !valid, and !(is_shortname
>  > && base_info.valid && ext_info.valid) or add "else" part is more prefer
>  > though.
>
> ok, new patch below. 

Looks good to me as technical stand.

>  > Yes. The case-insensitive is ok, the dcache can handle case-insensitive.
>
> good, that makes life simpler :-)
>
> Are you happy with the shortname_flags hackery in
> vfat_create_shortname() ?

Ah. What is the intent to force WINNT option (lcase field)? To force it
may not be good. So, change default if config is on?
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[tridge]

 > Ah. What is the intent to force WINNT option (lcase field)? To force it
 > may not be good. So, change default if config is on?

The idea behind forcing it is that it maintains maximum
functionality without the user having to use special mount
options. For example, if a Linux user creates a file "README.txt" then
the name will be preserved exactly, whereas without that hackery it
becomes README.TXT on disk.

It does mean we are mixing up two things with that config option
though, which is why I asked you about it. Would you prefer to just
let the distros worry about the default mount options when someone
plugs in a VFAT device on a system with
CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES set? 

Or maybe we should change the defaults in parse_options() when this
option is set?

Cheers, Tridge

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[OGAWA Hirofumi]

tridge@samba.org writes:

>  > Ah. What is the intent to force WINNT option (lcase field)? To force it
>  > may not be good. So, change default if config is on?
>
> The idea behind forcing it is that it maintains maximum
> functionality without the user having to use special mount
> options. For example, if a Linux user creates a file "README.txt" then
> the name will be preserved exactly, whereas without that hackery it
> becomes README.TXT on disk.
>
> It does mean we are mixing up two things with that config option
> though, which is why I asked you about it. Would you prefer to just
> let the distros worry about the default mount options when someone
> plugs in a VFAT device on a system with
> CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES set? 

I see.

> Or maybe we should change the defaults in parse_options() when this
> option is set?

Current default (shortname=lower) is just for historically reason.
Personally, I'm thinking it's not good as default ("winnt" or "mixed" is
prefer).

Anyway, I'm not sure though, I guess to change the default is good than
force it at least, because it would be the user policy.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[tridge]

 > Current default (shortname=lower) is just for historically reason.
 > Personally, I'm thinking it's not good as default ("winnt" or "mixed" is
 > prefer).

It might make sense to make the default depend on the fs type. For
example, make FAT32 use "winnt" and FAT12/16 use "mixed". That would
give maximum interoperability I think.

I'm presuming that the versions of win95 that supported FAT32 also
supported the mixed case bits, though I haven't tested that.

Cheers, Tridge

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[OGAWA Hirofumi]

tridge@samba.org writes:

>  > Current default (shortname=lower) is just for historically reason.
>  > Personally, I'm thinking it's not good as default ("winnt" or "mixed" is
>  > prefer).
>
> It might make sense to make the default depend on the fs type. For
> example, make FAT32 use "winnt" and FAT12/16 use "mixed". That would
> give maximum interoperability I think.
>
> I'm presuming that the versions of win95 that supported FAT32 also
> supported the mixed case bits, though I haven't tested that.

"mixed" means created like win95, but support to read winnt field. So,
it is compatible to win95. And even if user is using winnt option, the
file created can be readed on win95, win95 will ignore the lcase field,
and just display filename as upper case though.

I.e. created filename by any options can read on any plathome, it may
ignore the lcase field though. And, even if user is using "winnt", many
plathome wouldn't be supporting it.

Well, I think changing default by fstype is confusable.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Pavel Machek]

On Fri 2009-05-01 12:41:29, Dave Kleikamp wrote:
> From: Andrew Tridgell <tridge@samba.org>
> Subject: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option
> 
> When this option is enabled the VFAT filesystem 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.


CONFIG_AVOID_MS_PATENTS ?

									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[vimal singh]

Any conclusion has been reached reagarding this patch...?

---
vimal

On Sat, May 2, 2009 at 5:29 PM, OGAWA Hirofumi
<hirofumi@mail.parknet.co.jp> wrote:
> tridge@samba.org writes:
>
>>  > Yes. I guess -ENAMETOOLONG would not good for !valid, and !(is_shortname
>>  > && base_info.valid && ext_info.valid) or add "else" part is more prefer
>>  > though.
>>
>> ok, new patch below.
>
> Looks good to me as technical stand.
>
>>  > Yes. The case-insensitive is ok, the dcache can handle case-insensitive.
>>
>> good, that makes life simpler :-)
>>
>> Are you happy with the shortname_flags hackery in
>> vfat_create_shortname() ?
>
> Ah. What is the intent to force WINNT option (lcase field)? To force it
> may not be good. So, change default if config is on?
> --
> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[tridge]

Hi Vimal,

 > Any conclusion has been reached reagarding this patch...?

We've been working to resolve some of the issues people raised (for
example, a public explanation on why the patch is needed). We have
also been working towards an improved version of the patch. Sorry it's
taking so long, but we hope to be able to post a new patch soon.

Cheers, Tridge

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[vimal singh]

On Thu, May 28, 2009 at 5:27 AM,  <tridge@samba.org> wrote:
> Hi Vimal,
>
>  > Any conclusion has been reached reagarding this patch...?
>
> We've been working to resolve some of the issues people raised (for
> example, a public explanation on why the patch is needed). We have
> also been working towards an improved version of the patch. Sorry it's
> taking so long, but we hope to be able to post a new patch soon.
Is there any problem in previous patch, which you looking to fix in
the new version? Or these are all non-technical issues.
Can I take this patch for as of now?

-vimal

>
> Cheers, Tridge
>



-- 
---
Regards,
\/ | |\/| /-\ |_

____      __o
------   -\<,
-----  ( )/ ( )
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[tridge]

Hi Vimal,

 > Is there any problem in previous patch, which you looking to fix in
 > the new version? Or these are all non-technical issues.

The previous patch is fine, although as several people pointed out it
lacked a public explanation of why it is needed. We are working on
fixing that. We are also working towards the release of a new patch
that has some advantages in terms of what functionality is lost when
the patch is enabled.

 > Can I take this patch for as of now?

yes, there are no issues with the patch we sent that would prevent
anyone using it, it just lacks an explanation and loses more
functionality than is strictly necessary.

Cheers, Tridge

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Steve French]

On Tue, May 5, 2009 at 4:04 PM, Christoph Hellwig <hch@infradead.org> wrote:
> On Tue, May 05, 2009 at 04:56:30PM -0400, Valdis.Kletnieks@vt.edu wrote:
>> Well, VFAT was in Windows for Workgroups 3.11 or so, back in 1982, and a patent
>
> VFAT was introduced in Windows 95.  OS/2 had it's own long filename
> extensions longe before as did Linux (umsdos)
Yes, Christoph is correct we did implement long file name support long
ago in OS/2.

OS/2 long filenames for FAT were stored as the .LONGFILE extended
attribute.  With
extended attribute emulation on vfat a similar approach could be used, although
presumably with different ondisk format for "EA DATA. SF" system file (which
stores extended attributes).   If anyone is interested in more detail on this
(probably would be boring to most), we can explain the details.



-- 
Thanks,

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Paul E. McKenney]

On Tue, May 05, 2009 at 05:00:08PM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 05 May 2009 08:35:27 PDT, "Paul E. McKenney" said:
> 
> > http://books.google.com/books?id=6je0tPcGMzYC&pg=PT822&lpg=PT822&dq=Videotron
> ics+v.+Bend+Electronics,+586+F.Supp.+478,+481+(D.+Nev.+1984)&source=bl&ots=ccxO
> 5np_uQ&sig=Q0wj4k5uCpMiZybAQe12JlHhh0A&hl=en&ei=Z1kASu2ZJ8eLtgehupyNBw&sa=X&oi=
> book_result&ct=result&resnum=2#PPT822,M1
> > 
> > Dated 2005, cites a 1988 case in footnote 28.  Also claims that:
> 
> That would be the same Neundorfer case I found.
> 
> > Copyright Office II Compendium of Copyright Office Practices lists
> > acceptable variants to the C in a circle, including "(c)".
> 
> http://www.copyright.gov/compendium/ - I ain't seeing it in there anyplace?
> Every occurrence of "(c)" is in either a USC or CFR citation. But of course
> that only shows the two chapters modified since 1998. Yee-hah. :)

Indeed!  :-/

> I suspect it's one of those dark corners of the legal system that nobody
> really wants to explore, because there might be a Balrog hiding in the depths
> (sort of like the question "Which clause/theory of copyright law authorizes
> the copy of a webpage you make while downloading it to read it?" ;)

;-)

							Thanx, Paul

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Christoph Hellwig]

On Tue, May 05, 2009 at 04:56:30PM -0400, Valdis.Kletnieks@vt.edu wrote:
> Well, VFAT was in Windows for Workgroups 3.11 or so, back in 1982, and a patent

VFAT was introduced in Windows 95.  OS/2 had it's own long filename
extensions longe before as did Linux (umsdos)

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

On Tue, 05 May 2009 08:35:27 PDT, "Paul E. McKenney" said:

> http://books.google.com/books?id=6je0tPcGMzYC&pg=PT822&lpg=PT822&dq=Videotron
ics+v.+Bend+Electronics,+586+F.Supp.+478,+481+(D.+Nev.+1984)&source=bl&ots=ccxO
5np_uQ&sig=Q0wj4k5uCpMiZybAQe12JlHhh0A&hl=en&ei=Z1kASu2ZJ8eLtgehupyNBw&sa=X&oi=
book_result&ct=result&resnum=2#PPT822,M1
> 
> Dated 2005, cites a 1988 case in footnote 28.  Also claims that:

That would be the same Neundorfer case I found.

> Copyright Office II Compendium of Copyright Office Practices lists
> acceptable variants to the C in a circle, including "(c)".

http://www.copyright.gov/compendium/ - I ain't seeing it in there anyplace?
Every occurrence of "(c)" is in either a USC or CFR citation. But of course
that only shows the two chapters modified since 1998. Yee-hah. :)

I suspect it's one of those dark corners of the legal system that nobody
really wants to explore, because there might be a Balrog hiding in the depths
(sort of like the question "Which clause/theory of copyright law authorizes
the copy of a webpage you make while downloading it to read it?" ;)




[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 994 bytes --]

On Tue, 05 May 2009 20:39:05 +0930, David Newall said:

> Whether your patch goes in; whether it doesn't; it now seems there's
> something fishy about long filenames, and to be safe, perhaps it would
> be better to just turn off anything to do with FAT filesystems.  Who
> would care, right?  Unless i turns out that Linux no longer has the
> essential features.
> 
> Unless disrupting Linux was the point, and of course it isn't, it seems
> that full disclosure is required.  And that's before any patch should
> even be looked at.

Well, VFAT was in Windows for Workgroups 3.11 or so, back in 1982, and a patent
only runs 17 years.  So that clock's been ticking for quite some time.  Heck,
one could probably make a case that if Microsoft hasn't officially squawked
*yet* about code that infringes on anything that was released in '82, that
they've basically estoppell'd themselves.

Of course, some spoil-sport is going to come along and say that submarine
patents don't work that way. ;)



[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Paul E. McKenney]

On Tue, May 05, 2009 at 04:05:58AM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Mon, 04 May 2009 20:34:42 PDT, "Paul E. McKenney" said:
> 
> > I am more than happy to let you search the case law on this one.
> 
> Ya know, it's that same "I'll let your lawyers rediscover the stuff that mine
> already found" issue that's making this thread a pain.

My apologies for the pain, however, Matthew said that he "never trusted
advice from IBM laywers", so there didn't seem to be any point in
consulting them.

> Case saying (C) *possibly* sufficient (ruling 'c-in-hexagon' was sufficient):
> Videotronics v. Bend Electronics, 586 F.Supp. 478, 481 (D. Nev. 1984)
> 
> Case saying it might not be:
> Forry v. Neundorfer, 837 F.2d 259, 266 (6th Cir., 1988)
> 
> Neundorfer says:
> 
> "Videotronics, Inc. v. Bend Electronics, 586 F.Supp. 478 (D.Nev.1984) held that
> a letter "C" enclosed within a hexagon met the statutory requirements, but
> suggested in dicta that the symbol "(C)" might not be sufficient because
> parentheses, unlike a hexagon or a circle, would not completely enclose the
> "C". Id. at 481. However, if a "C" in a hexagon is sufficient, an argument
> exists that a "C" in parentheses is sufficient. Defendants here had actual
> notice of copyright. The trial of this action may provide a better record on
> which to finally decide whether the symbol "(C)" is sufficiently similar to a
> "C" in a circle to serve as notice of a copyright. Plaintiff is apparently now
> using the "C" in a circle. It may therefore be entitled to rely on 405(a)(2)
> even if the earlier symbol was not sufficient."
> 
> Clear as mud, unless you have a more recent cite. :)

http://books.google.com/books?id=6je0tPcGMzYC&pg=PT822&lpg=PT822&dq=Videotronics+v.+Bend+Electronics,+586+F.Supp.+478,+481+(D.+Nev.+1984)&source=bl&ots=ccxO5np_uQ&sig=Q0wj4k5uCpMiZybAQe12JlHhh0A&hl=en&ei=Z1kASu2ZJ8eLtgehupyNBw&sa=X&oi=book_result&ct=result&resnum=2#PPT822,M1

Dated 2005, cites a 1988 case in footnote 28.  Also claims that:
Copyright Office II Compendium of Copyright Office Practices lists
acceptable variants to the C in a circle, including "(c)".

But this is a USA publication.  Perhaps Matthew is thinking in terms of
some other geography.  And perhaps things have changed since 2005.

							Thanx, Paul

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[David Newall]

Theodore Tso wrote:
> On Mon, May 04, 2009 at 09:30:20AM -0700, Eric W. Biederman wrote:
>   
>> When all of the pieces are public how can having secret veiled reasons
>> make sense?
>>     
>
> Legal reasoning and strategy often needs to be kept confidential.

But those needs must defer to the open and public nature of the kernel. 
When you propose a change without saying why you giving the clear and
strong impression that something secret is going down and we should just
trust you.  That puts everyone in an awkward position because there's
now a risk that can't be properly evaluated.

Whether your patch goes in; whether it doesn't; it now seems there's
something fishy about long filenames, and to be safe, perhaps it would
be better to just turn off anything to do with FAT filesystems.  Who
would care, right?  Unless i turns out that Linux no longer has the
essential features.

Unless disrupting Linux was the point, and of course it isn't, it seems
that full disclosure is required.  And that's before any patch should
even be looked at.

> Note: We don't always ask people for the reason behind why they want,
> say, cgroups to control I/O throttling for example.  They may have a
> secret business case for how they will be able to leverage that
> technology with some application stack to make tons and tons of money
> --- and we don't require that deep motives be revealed in those cases.
>   

One might not  give the deep reason, but if no sufficient reason is
given then there's no sufficient reason and the answer is no.  We don't
want features just for the sake of another knob to twiddle.  It has to
be a *useful* knob.


> Or possibly it's because it is believed that [a patent] could be
> invalidated,
> which is why OIN is requesting prior art even though the last time to
> invalidate the patent through prior art was denied by the patent
> office.

Whether or not it's disclosed, you have to believe that any change
related to a patent issue will be noticed by people interested in that
issue.  You can make a disclosure without making an admission or claim. 
And then everybody understands what's going on.

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]

On Mon, 04 May 2009 20:34:42 PDT, "Paul E. McKenney" said:

> I am more than happy to let you search the case law on this one.

Ya know, it's that same "I'll let your lawyers rediscover the stuff that mine
already found" issue that's making this thread a pain.

Case saying (C) *possibly* sufficient (ruling 'c-in-hexagon' was sufficient):
Videotronics v. Bend Electronics, 586 F.Supp. 478, 481 (D. Nev. 1984)

Case saying it might not be:
Forry v. Neundorfer, 837 F.2d 259, 266 (6th Cir., 1988)

Neundorfer says:

"Videotronics, Inc. v. Bend Electronics, 586 F.Supp. 478 (D.Nev.1984) held that
a letter "C" enclosed within a hexagon met the statutory requirements, but
suggested in dicta that the symbol "(C)" might not be sufficient because
parentheses, unlike a hexagon or a circle, would not completely enclose the
"C". Id. at 481. However, if a "C" in a hexagon is sufficient, an argument
exists that a "C" in parentheses is sufficient. Defendants here had actual
notice of copyright. The trial of this action may provide a better record on
which to finally decide whether the symbol "(C)" is sufficiently similar to a
"C" in a circle to serve as notice of a copyright. Plaintiff is apparently now
using the "C" in a circle. It may therefore be entitled to rely on 405(a)(2)
even if the earlier symbol was not sufficient."

Clear as mud, unless you have a more recent cite. :)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Paul E. McKenney]

On Mon, May 04, 2009 at 08:18:53PM -0600, Matthew Wilcox wrote:
> On Mon, May 04, 2009 at 07:11:21PM -0700, Paul E. McKenney wrote:
> > On Mon, May 04, 2009 at 08:01:49PM -0600, Matthew Wilcox wrote:
> > > On Mon, May 04, 2009 at 03:12:08PM -0700, Greg KH wrote:
> > > > But what was wrong with what they told us to do with regards to how to
> > > > specify the copyright on a file?  I don't recall seeing anything that
> > > > contridicted what I was told, but that was many many years ago, so I
> > > > probably am forgetting...
> > > 
> > > I don't remember exactly, and can't be bothered to look it up.  It was
> > > something along the lines of you saying an IBM lawyer had told you
> > > that in:
> > > 
> > > Copyright (c) 2009
> > > 
> > > the (c) was a non-optional part.  I found something that said the (c)
> > > had no legal meaning.
> > 
> > http://www.copyright.gov/circs/circ1.pdf
> > 
> > Page 4, bottom of first column through second column.
> 
> That notices actually aren't needed any more?  Yes.  The bit I was
> referring to was this:
> 
> 1	 The symbol © (the letter C in a circle), or the word
>   "Copyright," or the abbreviation "Copr."; and
> 
> In particular, I've seen elsewhere that (c) is not a valid representation
> of 'the letter C in a circle'.

I am more than happy to let you search the case law on this one.

							Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 536 bytes --]

On Mon, 04 May 2009 19:11:21 PDT, "Paul E. McKenney" said:
 
> http://www.copyright.gov/circs/circ1.pdf
> 
> Page 4, bottom of first column through second column.

And that says:

	 The symbol © (the letter C in a circle), or the word
  "Copyright," or the abbreviation "Copr." and

The 3 byte sequence ( c ) is different than the UTF-8 character known as
"U+00A9	c2 a9	COPYRIGHT SIGN".  If you can find an actual citation that
the 3-byte sequence c-between-parens has the same legal meaning as c-in-circle,
bring it on.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Matthew Wilcox]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 1613 bytes --]

On Mon, May 04, 2009 at 07:11:21PM -0700, Paul E. McKenney wrote:
> On Mon, May 04, 2009 at 08:01:49PM -0600, Matthew Wilcox wrote:
> > On Mon, May 04, 2009 at 03:12:08PM -0700, Greg KH wrote:
> > > But what was wrong with what they told us to do with regards to how to
> > > specify the copyright on a file?  I don't recall seeing anything that
> > > contridicted what I was told, but that was many many years ago, so I
> > > probably am forgetting...
> > 
> > I don't remember exactly, and can't be bothered to look it up.  It was
> > something along the lines of you saying an IBM lawyer had told you
> > that in:
> > 
> > Copyright (c) 2009
> > 
> > the (c) was a non-optional part.  I found something that said the (c)
> > had no legal meaning.
> 
> http://www.copyright.gov/circs/circ1.pdf
> 
> Page 4, bottom of first column through second column.

That notices actually aren't needed any more?  Yes.  The bit I was
referring to was this:

1	 The symbol © (the letter C in a circle), or the word
  "Copyright," or the abbreviation "Copr."; and

In particular, I've seen elsewhere that (c) is not a valid representation
of 'the letter C in a circle'.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Paul E. McKenney]

On Mon, May 04, 2009 at 08:01:49PM -0600, Matthew Wilcox wrote:
> On Mon, May 04, 2009 at 03:12:08PM -0700, Greg KH wrote:
> > But what was wrong with what they told us to do with regards to how to
> > specify the copyright on a file?  I don't recall seeing anything that
> > contridicted what I was told, but that was many many years ago, so I
> > probably am forgetting...
> 
> I don't remember exactly, and can't be bothered to look it up.  It was
> something along the lines of you saying an IBM lawyer had told you
> that in:
> 
> Copyright (c) 2009
> 
> the (c) was a non-optional part.  I found something that said the (c)
> had no legal meaning.

http://www.copyright.gov/circs/circ1.pdf

Page 4, bottom of first column through second column.

							Thanx, Paul

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Matthew Wilcox]

On Mon, May 04, 2009 at 03:12:08PM -0700, Greg KH wrote:
> But what was wrong with what they told us to do with regards to how to
> specify the copyright on a file?  I don't recall seeing anything that
> contridicted what I was told, but that was many many years ago, so I
> probably am forgetting...

I don't remember exactly, and can't be bothered to look it up.  It was
something along the lines of you saying an IBM lawyer had told you
that in:

Copyright (c) 2009

the (c) was a non-optional part.  I found something that said the (c)
had no legal meaning.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Theodore Tso]

On Mon, May 04, 2009 at 09:30:20AM -0700, Eric W. Biederman wrote:
> Dave Kleikamp <shaggy@linux.vnet.ibm.com> writes:
> 
> > That's for the maintainers to decide.  If they agree it has worth, maybe
> > it's a good idea to answer "How".
> 
> Al and Christoph said essentially the same thing and they generally
> are considered the general area filesystem maintainers.

Ultimately the folks that is will be primarily making this decision is
Ogawa Hirofumi-san, as the FAT/VFAT maintainer, and Linus Torvalds, of
course.  So I'm not sure this thread is actually all that productive,
unless we can move it back to talking about the technical issues.

> When all of the pieces are public how can having secret veiled reasons
> make sense?

Legal reasoning and strategy often needs to be kept confidential.  It
may not make a lot of sense, but in the real world, lawyers can do a
lot of harm (and good) and in their area of expertise, I tend to defer
to their judgement, just as I defer to an airplane pilot on how to
safely fly me from Boston to Amsterdam.

I will observe (again) that Digital Camera manufacturers, and the
folks who came up with the DCIM standard, have for the last 10+ years
explicitly used a scheme where their cameras do not need to create
anything other than 8.3 filenames.  So at least for those folks, the
FAT Long Filename support is bloat which they don't need or want.
Furthermore, their decision to avoid anything other tghan 8.3
filenames goes back far before any patent lawsuits or settlements that
people have alleged as being related to the "why" of the patch.  Every
single digital camera does not need long file names; they all use 8.3
filenames *only* in accordance with the DCIM standard.  Is bloat
avoidance for digital cameras manufacturers who want to use Linux a
good enough reason for you?

Note: We don't always ask people for the reason behind why they want,
say, cgroups to control I/O throttling for example.  They may have a
secret business case for how they will be able to leverage that
technology with some application stack to make tons and tons of money
--- and we don't require that deep motives be revealed in those cases.
If the "what" and "how" of the patch makes sense, there is at least
one valid use case for the "why", that's often enough.  And we ought
to consider whether or not the needs of digital camera manfactuers who
might have firmware bloat requirements and who have decided over a
decade ago that 8.3 filenames were just fine for writing images to
flash cards, is a good enough reason.  Think of it as a bloatwatch
exercise, if that makes you happy.  :-)

> And if secret magic consultations with lawyers are going to be invoked
> I expect we should have a Signed-off-by from those lawyers.

That certainly wouldn't make any sense.  The lawyers didn't originate
the patch, and the code didn't pass through their hands.  Maybe a
reviewed-by or an acked-by, though.  :-)

On Mon, May 04, 2009 at 02:53:41PM -0600, Chris Friesen wrote:
>
>> Or that patent is believed to be invalid and faught, and there was
>> absolute no reason to remove it except for companies doing as part of a
>> settlement and they could do it in their privat trees.
>
> What about the scenario where a patent is valid in certain parts of the  
> world but not in others?  It seems possible that in this scenario there  
> may be valid reasons to have a config option.

Quite possibly.  

Or possibly it's because it is believed that it could be invalidated,
which is why OIN is requesting prior art even though the last time to
invalidate the patent through prior art was denied by the patent
office.  (And note, if a patent is challenged, and survives the
challenge, it gets stronger by receiving more deference from the
courts; and if it survives a second change, it gets even stronger, and
can for all practical purposes, become unchallengeable --- which is
why you don't challenge patents lightly; so I would imagine the OIN
will tread very, **very** carefully before submitting a second
challenge to the USPTO --- which is probably why the OIN *has* made a
public appeal for as much prior art as people can find; even if they
do have some good stuff, you want as much ammunition as you can,
potentially since the USPTO has refused to admit they were wrong the
first time around.)

And in the meantime, perhaps there is a desire not to fuel any FUD as
well as not wanting removing very useful functionality that desktop
users might care about over bogus patent(s), but at the same time make
it easier for companies who might not have the multiple millions of
dollars that it takes to defend against a patent lawsuit, whether or
not the patent is bullsh*t or not.

					- Ted

P.S.  Ob.Disclaimer: The above is my opinion only, and and doesn't
necessarily represent IBM or the Linux Foundation's positions,
strategies, or opinions.  I have not privately discussed this issue
with any IBM employee, contractor, or lawyer (i.e., not besides
reading the public e-mails on LKML and reading the public Ars Technica
articles on the subject).  Most of what I know about patents from an
semester-long class taught at the MIT Sloan School of Business which
covered, quite extensively, Intellectual Property Law.  Unfortunately,
it's a very good thing for a programmer to be understand; perhaps that
says something about the society we live in.

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Greg KH]

On Mon, May 04, 2009 at 10:22:52AM -0600, Matthew Wilcox wrote:
> On Mon, May 04, 2009 at 09:10:24AM -0700, Paul E. McKenney wrote:
> > On Mon, May 04, 2009 at 09:55:06AM -0600, Matthew Wilcox wrote:
> > > Indeed I do have access to lawyers.  But what use is that?  I could
> > > presumably get an opinion for myself that I would not then be able to
> > > share outside of Intel.
> > 
> > I am glad you understand our situation, then!  ;-)
> 
> I'm assuming my situation would be analagous to yours.  That doesn't
> mean that I understand your situation at all.
> 
> > > Can't you get the SFLC to issue a public legal opinion for you?  Or maybe
> > > the Linux Foundation?
> > 
> > I have no clue whether this would work, but it is certainly worth
> > exploring.  Thank you for the tip!!!
> 
> No problem.  I'm always looking for ways to solve problems.
> 
> I've never trusted advice from IBM laywers, ever since Greg spouted some
> utter rubbish about the Copyright symbol that completely contradicts
> US law.

Doubt is good when dealing with lawyers :)

But what was wrong with what they told us to do with regards to how to
specify the copyright on a file?  I don't recall seeing anything that
contridicted what I was told, but that was many many years ago, so I
probably am forgetting...

thanks,

greg k-h

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Chris Friesen]

Christoph Hellwig wrote:

> Because of that let us assume that IBM Corporate, Paul E. McKenney, Andrew
> Tridgell and other know what code exactly infridges that patent.  IBM
> has worked around that code in the various embedded Linux offerings they
> ship and probably urge distributors to disable it.  Why would we not
> remove that code unconditionally in that case and let other people
> infridge it?
> 
> Or that patent is believed to be invalid and faught, and there was
> absolute no reason to remove it except for companies doing as part of a
> settlement and they could do it in their privat trees.

What about the scenario where a patent is valid in certain parts of the 
world but not in others?  It seems possible that in this scenario there 
may be valid reasons to have a config option.

Chris

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Paul E. McKenney]

On Mon, May 04, 2009 at 07:17:27PM +0100, Al Viro wrote:
> On Mon, May 04, 2009 at 09:42:50AM -0700, Paul E. McKenney wrote:
> 
> > Matthew's idea of checking with SFLC seems to me to have some merit.
> > I am looking into this from my end.  Of course, you and Al and Christoph
> > have just as much standing to ask SFLC as do I, and perhaps more.
> 
> OK, enough.  Any further communication on that topic should be filtered
> through lawyers, since you apparently refuse to provide details of rationale
> for your changes due to some kind of legal issues.

Hmmm...  Sorry you feel that way.  I had hoped to avoid having you deal
directly with lawyers, but perhaps that is the way that it must be.

If so, welcome to my world.

> Whether you have a reason for such behaviour or not, continuing that thread
> is obviously pointless.  If you want a useful review, it is up to you to
> figure out the procedure that
> 	(a) would allow answering such questions when asked by those who
> will be reviewing it
> 	(b) satisfy whatever legal concerns you might have about (a)
> 	(c) satisfy whatever legal concerns said reviewers might have
> regarding the procedure in question, whatever that procedure turns out
> to be.
> 	(d) satisfy whatever legal concerns employers of said reviewers
> might have.
> 
> Until then all you are doing is busily making an ass of yourself in public
> and possibly compounding whatever legal issues you might have.

This would not be the first time I have made an ass of myself in public,
and if things go as they normally do, it would not be the last.`

Unfortunately, I do not believe that this problem is going to go away on
its own.

							Thanx, Paul

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Al Viro]

On Mon, May 04, 2009 at 09:42:50AM -0700, Paul E. McKenney wrote:

> Matthew's idea of checking with SFLC seems to me to have some merit.
> I am looking into this from my end.  Of course, you and Al and Christoph
> have just as much standing to ask SFLC as do I, and perhaps more.

OK, enough.  Any further communication on that topic should be filtered
through lawyers, since you apparently refuse to provide details of rationale
for your changes due to some kind of legal issues.

Whether you have a reason for such behaviour or not, continuing that thread
is obviously pointless.  If you want a useful review, it is up to you to
figure out the procedure that
	(a) would allow answering such questions when asked by those who
will be reviewing it
	(b) satisfy whatever legal concerns you might have about (a)
	(c) satisfy whatever legal concerns said reviewers might have
regarding the procedure in question, whatever that procedure turns out
to be.
	(d) satisfy whatever legal concerns employers of said reviewers
might have.

Until then all you are doing is busily making an ass of yourself in public
and possibly compounding whatever legal issues you might have.

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Paul E. McKenney]

On Mon, May 04, 2009 at 11:54:14AM -0600, Matthew Wilcox wrote:
> On Mon, May 04, 2009 at 10:49:31AM -0700, Paul E. McKenney wrote:
> > Ah, but you are not simply asking us to -do- our homework, but also to
> > make that homework public on LKML.  Please note that Matthew's earlier
> > email indicates that he does not expect to be able to convince his
> > employer to make such homework public.
> 
> I have no data upon which to make a judgement as to the probability
> of my lawyer doing anything.  The implication I took away from your
> words earlier in this thread is that _no_ lawyer is going to permit
> this homework to be published.  Maybe Intel's lawyers differ with IBM's
> lawyers on this point.  I wouldn't know.

You could certainly ask them.

							Thanx, Paul

> But all you're hearing from me is an echo of your own assertions, not
> a concurrence.
> 
> -- 
> Matthew Wilcox				Intel Open Source Technology Centre
> "Bill, look, we understand that you're interested in selling us this
> operating system, but compare it to ours.  We can't possibly take such
> a retrograde step."

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Matthew Wilcox]

On Mon, May 04, 2009 at 10:49:31AM -0700, Paul E. McKenney wrote:
> Ah, but you are not simply asking us to -do- our homework, but also to
> make that homework public on LKML.  Please note that Matthew's earlier
> email indicates that he does not expect to be able to convince his
> employer to make such homework public.

I have no data upon which to make a judgement as to the probability
of my lawyer doing anything.  The implication I took away from your
words earlier in this thread is that _no_ lawyer is going to permit
this homework to be published.  Maybe Intel's lawyers differ with IBM's
lawyers on this point.  I wouldn't know.

But all you're hearing from me is an echo of your own assertions, not
a concurrence.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Paul E. McKenney]

On Mon, May 04, 2009 at 10:18:09AM -0700, Eric W. Biederman wrote:
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> writes:
> 
> > On Mon, May 04, 2009 at 09:30:20AM -0700, Eric W. Biederman wrote:
> >> Dave Kleikamp <shaggy@linux.vnet.ibm.com> writes:
> >> 
> >> > That's for the maintainers to decide.  If they agree it has worth, maybe
> >> > it's a good idea to answer "How".
> >> 
> >> Al and Christoph said essentially the same thing and they generally
> >> are considered the general area filesystem maintainers.
> >> 
> >> This kind of thing does not appear to have come up before and
> >> so procedurally you guys are setting are attempting to set
> >> a precedent.
> >> 
> >> All I know is that doing it the way you are doing seems like a bad
> >> idea.  Not discussing things or even the reason you can't discuss them
> >> seems foolish and leaves no one satisfied.
> >> 
> >> Maybe there are good reasons but so far this whole thing just stinks.
> >> 
> >> When all of the pieces are public how can having secret veiled reasons
> >> make sense?
> >> 
> >> And if secret magic consultations with lawyers are going to be invoked
> >> I expect we should have a Signed-off-by from those lawyers.
> >
> > ;-)
> >
> > Matthew's idea of checking with SFLC seems to me to have some merit.
> > I am looking into this from my end.  Of course, you and Al and Christoph
> > have just as much standing to ask SFLC as do I, and perhaps more.
> 
> Reasonable.  Of course it still misses one interesting point.
> 
> Typically when reviewing code if the code looks suspicious you ask the
> poster why they did X.  If the author of the code has a good answer
> you can tell that they have done their homework, and you can verify it.
> If the author doesn't have a good answer typically that means they haven't
> thought through all of the details and the code has problems.
> 
> In this case we ask why and get stone-walling.  Which typically would
> mean either that IBM has a good reason for doing this that they are
> keeping hidden.  Or that we have programmers reacting to news stories
> who have not done all of their homework.
> 
> So far my feeling has been, that there are people handling this mess
> on other fronts and that if it was a real issue they would be coming
> out of the wood work, and giving guidance.
> 
> Now perhaps no one is because this is a cross disciplinary thing and no
> one has sufficient legal, technical and business expertise.

It certainly is a cross-disciplinary thing.

> Right now my hypothesis that best fits the facts is programmers reacting
> on their own to news stories, without having done all of their homework.

Not the case, I assure you.  However, you are of course free to believe
whatever you choose.

> Asking others to go to the SFLC or other places and do your homework
> for you is an interesting reaction.  The SFLC does seem like an
> appropriate group to get an opinion from.

Ah, but you are not simply asking us to -do- our homework, but also to
make that homework public on LKML.  Please note that Matthew's earlier
email indicates that he does not expect to be able to convince his
employer to make such homework public.

As to requesting that SFLC weigh in, those of you from smaller
organizations might be able to accelerate this process significantly
should you care to do so.

							Thanx, Paul

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Christoph Hellwig]

On Mon, May 04, 2009 at 07:06:37PM +0200, Olivier Galibert wrote:
> Because knowingly violating a patent triples the damages, among other
> things.
> 
> There's a persistent rumor that a valid microsoft US software patent
> exists that covers the standard method of handling long file names on
> FAT filesystems.  It seems that such a patent is used by microsoft in
> litigations, the latest being against tomtom.  I think all of these
> litigations have been settled, but I can easily be wrong.
> 
> I have no idea whether such a patent actually exists, and even knowing
> the reference (I don't) I am not competent to judge what it covers or
> whether it would actually hold up in court.
> 
> But knowingly violating a patent is consider way worse in US courts
> than simple independant recreation.  So I guess the knowingly part is
> what the "you need a local lawyer" crowd tries to avoid.

And now we get a patch that introduces a configure option above code
dealing with longnames which disables a very specific piece of code.

Because of that let us assume that IBM Corporate, Paul E. McKenney, Andrew
Tridgell and other know what code exactly infridges that patent.  IBM
has worked around that code in the various embedded Linux offerings they
ship and probably urge distributors to disable it.  Why would we not
remove that code unconditionally in that case and let other people
infridge it?

Or that patent is believed to be invalid and faught, and there was
absolute no reason to remove it except for companies doing as part of a
settlement and they could do it in their privat trees.

Or both of the two above variants are wrong.  That's why we do need a
good description of what is actually happening, and I don't feel a
signed-off-by is justified if adds an option that can disable known
infringing code (if that actually is the case) but leaves it otherwise
if fine.  If it's not actually infringing we need an even better
explanation.

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Eric W. Biederman]

"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> writes:

> On Mon, May 04, 2009 at 09:30:20AM -0700, Eric W. Biederman wrote:
>> Dave Kleikamp <shaggy@linux.vnet.ibm.com> writes:
>> 
>> > That's for the maintainers to decide.  If they agree it has worth, maybe
>> > it's a good idea to answer "How".
>> 
>> Al and Christoph said essentially the same thing and they generally
>> are considered the general area filesystem maintainers.
>> 
>> This kind of thing does not appear to have come up before and
>> so procedurally you guys are setting are attempting to set
>> a precedent.
>> 
>> All I know is that doing it the way you are doing seems like a bad
>> idea.  Not discussing things or even the reason you can't discuss them
>> seems foolish and leaves no one satisfied.
>> 
>> Maybe there are good reasons but so far this whole thing just stinks.
>> 
>> When all of the pieces are public how can having secret veiled reasons
>> make sense?
>> 
>> And if secret magic consultations with lawyers are going to be invoked
>> I expect we should have a Signed-off-by from those lawyers.
>
> ;-)
>
> Matthew's idea of checking with SFLC seems to me to have some merit.
> I am looking into this from my end.  Of course, you and Al and Christoph
> have just as much standing to ask SFLC as do I, and perhaps more.

Reasonable.  Of course it still misses one interesting point.

Typically when reviewing code if the code looks suspicious you ask the
poster why they did X.  If the author of the code has a good answer
you can tell that they have done their homework, and you can verify it.
If the author doesn't have a good answer typically that means they haven't
thought through all of the details and the code has problems.

In this case we ask why and get stone-walling.  Which typically would
mean either that IBM has a good reason for doing this that they are
keeping hidden.  Or that we have programmers reacting to news stories
who have not done all of their homework.

So far my feeling has been, that there are people handling this mess
on other fronts and that if it was a real issue they would be coming
out of the wood work, and giving guidance.

Now perhaps no one is because this is a cross disciplinary thing and no
one has sufficient legal, technical and business expertise.

Right now my hypothesis that best fits the facts is programmers reacting
on their own to news stories, without having done all of their homework.

Asking others to go to the SFLC or other places and do your homework
for you is an interesting reaction.  The SFLC does seem like an
appropriate group to get an opinion from.

Eric

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Olivier Galibert]

On Mon, May 04, 2009 at 09:30:20AM -0700, Eric W. Biederman wrote:
> When all of the pieces are public how can having secret veiled reasons
> make sense?

Because knowingly violating a patent triples the damages, among other
things.

There's a persistent rumor that a valid microsoft US software patent
exists that covers the standard method of handling long file names on
FAT filesystems.  It seems that such a patent is used by microsoft in
litigations, the latest being against tomtom.  I think all of these
litigations have been settled, but I can easily be wrong.

I have no idea whether such a patent actually exists, and even knowing
the reference (I don't) I am not competent to judge what it covers or
whether it would actually hold up in court.

But knowingly violating a patent is consider way worse in US courts
than simple independant recreation.  So I guess the knowingly part is
what the "you need a local lawyer" crowd tries to avoid.

  OG.

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Paul E. McKenney]

On Mon, May 04, 2009 at 09:30:20AM -0700, Eric W. Biederman wrote:
> Dave Kleikamp <shaggy@linux.vnet.ibm.com> writes:
> 
> > That's for the maintainers to decide.  If they agree it has worth, maybe
> > it's a good idea to answer "How".
> 
> Al and Christoph said essentially the same thing and they generally
> are considered the general area filesystem maintainers.
> 
> This kind of thing does not appear to have come up before and
> so procedurally you guys are setting are attempting to set
> a precedent.
> 
> All I know is that doing it the way you are doing seems like a bad
> idea.  Not discussing things or even the reason you can't discuss them
> seems foolish and leaves no one satisfied.
> 
> Maybe there are good reasons but so far this whole thing just stinks.
> 
> When all of the pieces are public how can having secret veiled reasons
> make sense?
> 
> And if secret magic consultations with lawyers are going to be invoked
> I expect we should have a Signed-off-by from those lawyers.

;-)

Matthew's idea of checking with SFLC seems to me to have some merit.
I am looking into this from my end.  Of course, you and Al and Christoph
have just as much standing to ask SFLC as do I, and perhaps more.

							Thanx, Paul

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Eric W. Biederman]

Dave Kleikamp <shaggy@linux.vnet.ibm.com> writes:

> That's for the maintainers to decide.  If they agree it has worth, maybe
> it's a good idea to answer "How".

Al and Christoph said essentially the same thing and they generally
are considered the general area filesystem maintainers.

This kind of thing does not appear to have come up before and
so procedurally you guys are setting are attempting to set
a precedent.

All I know is that doing it the way you are doing seems like a bad
idea.  Not discussing things or even the reason you can't discuss them
seems foolish and leaves no one satisfied.

Maybe there are good reasons but so far this whole thing just stinks.

When all of the pieces are public how can having secret veiled reasons
make sense?

And if secret magic consultations with lawyers are going to be invoked
I expect we should have a Signed-off-by from those lawyers.

Eric

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Matthew Wilcox]

On Mon, May 04, 2009 at 09:10:24AM -0700, Paul E. McKenney wrote:
> On Mon, May 04, 2009 at 09:55:06AM -0600, Matthew Wilcox wrote:
> > Indeed I do have access to lawyers.  But what use is that?  I could
> > presumably get an opinion for myself that I would not then be able to
> > share outside of Intel.
> 
> I am glad you understand our situation, then!  ;-)

I'm assuming my situation would be analagous to yours.  That doesn't
mean that I understand your situation at all.

> > Can't you get the SFLC to issue a public legal opinion for you?  Or maybe
> > the Linux Foundation?
> 
> I have no clue whether this would work, but it is certainly worth
> exploring.  Thank you for the tip!!!

No problem.  I'm always looking for ways to solve problems.

I've never trusted advice from IBM laywers, ever since Greg spouted some
utter rubbish about the Copyright symbol that completely contradicts
US law.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Paul E. McKenney]

On Mon, May 04, 2009 at 08:59:14AM -0700, Eric W. Biederman wrote:
> Dave Kleikamp <shaggy@linux.vnet.ibm.com> writes:
> 
> > On Mon, 2009-05-04 at 09:08 -0600, Matthew Wilcox wrote:
> >> On Mon, May 04, 2009 at 07:39:19AM -0700, Paul E. McKenney wrote:
> >> > On Mon, May 04, 2009 at 07:21:19AM -0600, Matthew Wilcox wrote:
> >> > > Bringing the patch to a public mailing list is a waste of time until
> >> > > there's a reliable description of the problem you're trying to solve.
> >> > 
> >> > Please see the original patch.  It does describes what it is doing.
> >> 
> >> "What", but not "Why".  Which is only acceptable in GNU changelogs ;-)
> >
> > Please understand the "Why" is a sticky subject that we can't and won't
> > discuss in a public forum.  However, we believe the maintainers
> > understand the "Why" of it well enough to consider whether or not to
> > include such a patch.  The "What" should be pretty clear from the patch
> > description.  The "How" is a technical question that can be discussed
> > here.
> 
> If the "Why" can not be discussed then you don't have a "Why" you can
> stand behind.

Nice try.

> If you don't have a "Why" you can stand behind the "Why" sucks and does
> not appear to be an appropriate justification for a patch applied to
> a public piece of code.

Again, nice try.

							Thanx, Paul

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Paul E. McKenney]

On Mon, May 04, 2009 at 11:55:41AM -0400, Christoph Hellwig wrote:
> On Mon, May 04, 2009 at 08:38:15AM -0700, Paul E. McKenney wrote:
> > Given your affiliation, you should have access to people with whom
> > you can have a meaningful conversation on the non-technical issues,
> > but without putting the Linux community at risk.
> 
> You could please stop that elitest crap?  Either you guys come up
> with a good explanation for that patch or you go away, thanks.

Where you would be the sole arbiter of "good", I take it?  You had best
get trained up on non-technical topics, then.  ;-)

							Thanx, Paul

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Paul E. McKenney]

On Mon, May 04, 2009 at 09:55:06AM -0600, Matthew Wilcox wrote:
> On Mon, May 04, 2009 at 08:38:15AM -0700, Paul E. McKenney wrote:
> > On Mon, May 04, 2009 at 09:08:34AM -0600, Matthew Wilcox wrote:
> > > On Mon, May 04, 2009 at 07:39:19AM -0700, Paul E. McKenney wrote:
> > > > On Mon, May 04, 2009 at 07:21:19AM -0600, Matthew Wilcox wrote:
> > > > > Bringing the patch to a public mailing list is a waste of time until
> > > > > there's a reliable description of the problem you're trying to solve.
> > > > 
> > > > Please see the original patch.  It does describes what it is doing.
> > > 
> > > "What", but not "Why".  Which is only acceptable in GNU changelogs ;-)
> > 
> > ;-)
> > 
> > > Matthew Wilcox			Intel Open Source Technology Centre
> > 
> > Given your affiliation, you should have access to people with whom
> > you can have a meaningful conversation on the non-technical issues,
> > but without putting the Linux community at risk.
> 
> Indeed I do have access to lawyers.  But what use is that?  I could
> presumably get an opinion for myself that I would not then be able to
> share outside of Intel.

I am glad you understand our situation, then!  ;-)

> Can't you get the SFLC to issue a public legal opinion for you?  Or maybe
> the Linux Foundation?

I have no clue whether this would work, but it is certainly worth
exploring.  Thank you for the tip!!!

							Thanx, Paul

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Dave Kleikamp]

On Mon, 2009-05-04 at 08:59 -0700, Eric W. Biederman wrote:
> Dave Kleikamp <shaggy@linux.vnet.ibm.com> writes:
> 
> > On Mon, 2009-05-04 at 09:08 -0600, Matthew Wilcox wrote:
> >> On Mon, May 04, 2009 at 07:39:19AM -0700, Paul E. McKenney wrote:
> >> > On Mon, May 04, 2009 at 07:21:19AM -0600, Matthew Wilcox wrote:
> >> > > Bringing the patch to a public mailing list is a waste of time until
> >> > > there's a reliable description of the problem you're trying to solve.
> >> > 
> >> > Please see the original patch.  It does describes what it is doing.
> >> 
> >> "What", but not "Why".  Which is only acceptable in GNU changelogs ;-)
> >
> > Please understand the "Why" is a sticky subject that we can't and won't
> > discuss in a public forum.  However, we believe the maintainers
> > understand the "Why" of it well enough to consider whether or not to
> > include such a patch.  The "What" should be pretty clear from the patch
> > description.  The "How" is a technical question that can be discussed
> > here.
> 
> If the "Why" can not be discussed then you don't have a "Why" you can
> stand behind.

That's for the maintainers to decide.  If they agree it has worth, maybe
it's a good idea to answer "How".

> If you don't have a "Why" you can stand behind the "Why" sucks and does
> not appear to be an appropriate justification for a patch applied to
> a public piece of code.

You're entitled to your opinion.
-- 
David Kleikamp
IBM Linux Technology Center

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Eric W. Biederman]

Dave Kleikamp <shaggy@linux.vnet.ibm.com> writes:

> On Mon, 2009-05-04 at 09:08 -0600, Matthew Wilcox wrote:
>> On Mon, May 04, 2009 at 07:39:19AM -0700, Paul E. McKenney wrote:
>> > On Mon, May 04, 2009 at 07:21:19AM -0600, Matthew Wilcox wrote:
>> > > Bringing the patch to a public mailing list is a waste of time until
>> > > there's a reliable description of the problem you're trying to solve.
>> > 
>> > Please see the original patch.  It does describes what it is doing.
>> 
>> "What", but not "Why".  Which is only acceptable in GNU changelogs ;-)
>
> Please understand the "Why" is a sticky subject that we can't and won't
> discuss in a public forum.  However, we believe the maintainers
> understand the "Why" of it well enough to consider whether or not to
> include such a patch.  The "What" should be pretty clear from the patch
> description.  The "How" is a technical question that can be discussed
> here.

If the "Why" can not be discussed then you don't have a "Why" you can
stand behind.

If you don't have a "Why" you can stand behind the "Why" sucks and does
not appear to be an appropriate justification for a patch applied to
a public piece of code.

Eric

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Christoph Hellwig]

On Mon, May 04, 2009 at 08:38:15AM -0700, Paul E. McKenney wrote:
> Given your affiliation, you should have access to people with whom
> you can have a meaningful conversation on the non-technical issues,
> but without putting the Linux community at risk.

You could please stop that elitest crap?  Either you guys come up
with a good explanation for that patch or you go away, thanks.

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Matthew Wilcox]

On Mon, May 04, 2009 at 08:38:15AM -0700, Paul E. McKenney wrote:
> On Mon, May 04, 2009 at 09:08:34AM -0600, Matthew Wilcox wrote:
> > On Mon, May 04, 2009 at 07:39:19AM -0700, Paul E. McKenney wrote:
> > > On Mon, May 04, 2009 at 07:21:19AM -0600, Matthew Wilcox wrote:
> > > > Bringing the patch to a public mailing list is a waste of time until
> > > > there's a reliable description of the problem you're trying to solve.
> > > 
> > > Please see the original patch.  It does describes what it is doing.
> > 
> > "What", but not "Why".  Which is only acceptable in GNU changelogs ;-)
> 
> ;-)
> 
> > Matthew Wilcox			Intel Open Source Technology Centre
> 
> Given your affiliation, you should have access to people with whom
> you can have a meaningful conversation on the non-technical issues,
> but without putting the Linux community at risk.

Indeed I do have access to lawyers.  But what use is that?  I could
presumably get an opinion for myself that I would not then be able to
share outside of Intel.

Can't you get the SFLC to issue a public legal opinion for you?  Or maybe
the Linux Foundation?

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 615 bytes --]

On Mon, 04 May 2009 08:25:05 +1000, tridge@samba.org said:

> I am trying to get that to happen, and I do realise that getting a
> lawyer to publicly explain the situation would be really
> worthwhile. Unfortunately lawyers are (mostly) very shy of making
> public statements of this type, because the legal consequences of
> making these statements can be non-trivial.

OK - so it isn't that you *can't* explain it yourself due to a gag order of
some sort, it's that it's a creeping horror convoluted mess and you're afraid
you'll stuff up the explanation without professional assistance.

Do I have that right?



[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Paul E. McKenney]

On Mon, May 04, 2009 at 09:08:34AM -0600, Matthew Wilcox wrote:
> On Mon, May 04, 2009 at 07:39:19AM -0700, Paul E. McKenney wrote:
> > On Mon, May 04, 2009 at 07:21:19AM -0600, Matthew Wilcox wrote:
> > > Bringing the patch to a public mailing list is a waste of time until
> > > there's a reliable description of the problem you're trying to solve.
> > 
> > Please see the original patch.  It does describes what it is doing.
> 
> "What", but not "Why".  Which is only acceptable in GNU changelogs ;-)

;-)

> Matthew Wilcox			Intel Open Source Technology Centre

Given your affiliation, you should have access to people with whom
you can have a meaningful conversation on the non-technical issues,
but without putting the Linux community at risk.

							Thanx, Paul

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Dave Kleikamp]

On Mon, 2009-05-04 at 09:08 -0600, Matthew Wilcox wrote:
> On Mon, May 04, 2009 at 07:39:19AM -0700, Paul E. McKenney wrote:
> > On Mon, May 04, 2009 at 07:21:19AM -0600, Matthew Wilcox wrote:
> > > Bringing the patch to a public mailing list is a waste of time until
> > > there's a reliable description of the problem you're trying to solve.
> > 
> > Please see the original patch.  It does describes what it is doing.
> 
> "What", but not "Why".  Which is only acceptable in GNU changelogs ;-)

Please understand the "Why" is a sticky subject that we can't and won't
discuss in a public forum.  However, we believe the maintainers
understand the "Why" of it well enough to consider whether or not to
include such a patch.  The "What" should be pretty clear from the patch
description.  The "How" is a technical question that can be discussed
here.

Thanks,
Shaggy
-- 
David Kleikamp
IBM Linux Technology Center

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Matthew Wilcox]

On Mon, May 04, 2009 at 07:39:19AM -0700, Paul E. McKenney wrote:
> On Mon, May 04, 2009 at 07:21:19AM -0600, Matthew Wilcox wrote:
> > Bringing the patch to a public mailing list is a waste of time until
> > there's a reliable description of the problem you're trying to solve.
> 
> Please see the original patch.  It does describes what it is doing.

"What", but not "Why".  Which is only acceptable in GNU changelogs ;-)

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Paul E. McKenney]

On Mon, May 04, 2009 at 07:21:19AM -0600, Matthew Wilcox wrote:
> On Mon, May 04, 2009 at 06:06:38AM -0700, Paul E. McKenney wrote:
> > On Mon, May 04, 2009 at 06:44:33AM -0600, Matthew Wilcox wrote:
> > > On Mon, May 04, 2009 at 05:41:29AM -0700, Paul E. McKenney wrote:
> > > > I am not sure that I correctly parsed these three sentences, but the
> > > > justification should be pretty clear to anyone who has been paying any
> > > > attention at all to recent industry news.
> > > 
> > > I think if there's one thing less reliable than an engineer's opinion
> > > on a patent, it's a journalist's opinion on a patent lawsuit.
> > 
> > And hence discussing these sorts of non-technical issues on LKML is kind
> > of pointless, you are saying?  I certainly cannot disagree with that!
> 
> Bringing the patch to a public mailing list is a waste of time until
> there's a reliable description of the problem you're trying to solve.

Please see the original patch.  It does describes what it is doing.

> All this innuendo is terribly unbecoming.

Ack that!!!

							Thanx, Paul

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Matthew Wilcox]

On Mon, May 04, 2009 at 06:06:38AM -0700, Paul E. McKenney wrote:
> On Mon, May 04, 2009 at 06:44:33AM -0600, Matthew Wilcox wrote:
> > On Mon, May 04, 2009 at 05:41:29AM -0700, Paul E. McKenney wrote:
> > > I am not sure that I correctly parsed these three sentences, but the
> > > justification should be pretty clear to anyone who has been paying any
> > > attention at all to recent industry news.
> > 
> > I think if there's one thing less reliable than an engineer's opinion
> > on a patent, it's a journalist's opinion on a patent lawsuit.
> 
> And hence discussing these sorts of non-technical issues on LKML is kind
> of pointless, you are saying?  I certainly cannot disagree with that!

Bringing the patch to a public mailing list is a waste of time until
there's a reliable description of the problem you're trying to solve.
All this innuendo is terribly unbecoming.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Paul E. McKenney]

On Mon, May 04, 2009 at 06:44:33AM -0600, Matthew Wilcox wrote:
> On Mon, May 04, 2009 at 05:41:29AM -0700, Paul E. McKenney wrote:
> > I am not sure that I correctly parsed these three sentences, but the
> > justification should be pretty clear to anyone who has been paying any
> > attention at all to recent industry news.
> 
> I think if there's one thing less reliable than an engineer's opinion
> on a patent, it's a journalist's opinion on a patent lawsuit.

And hence discussing these sorts of non-technical issues on LKML is kind
of pointless, you are saying?  I certainly cannot disagree with that!

						Thanx, Paul

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Matthew Wilcox]

On Mon, May 04, 2009 at 05:41:29AM -0700, Paul E. McKenney wrote:
> I am not sure that I correctly parsed these three sentences, but the
> justification should be pretty clear to anyone who has been paying any
> attention at all to recent industry news.

I think if there's one thing less reliable than an engineer's opinion
on a patent, it's a journalist's opinion on a patent lawsuit.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Paul E. McKenney]

On Sun, May 03, 2009 at 11:49:29PM -0700, Eric W. Biederman wrote:
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> writes:
> 
> > On Sun, May 03, 2009 at 10:42:52PM -0700, Eric W. Biederman wrote:
> >> The only reason I can see for not ultimately talking about things publicly
> >> is if this is one company making shady deals with another company in which
> >> case I do not see why the maintenance burden for those decision should
> >> fall on the linux community as a whole.
> >
> > Another reason is that past experience would indicate that anything we
> > say in public and and will be used against us.
> 
> Which is a fine reason to be careful what you say, and to say
> reasonable things.

I am glad you agree.

>                    It is not a reason to submit a patch without
> justification.
> 
> If the reason for submitting a patch is not sufficiently good to be
> held to then it appears insufficient to merge the patch.
> 
> Why should the commit to a position at your urging that you aren't
> willing to commit to?

I am not sure that I correctly parsed these three sentences, but the
justification should be pretty clear to anyone who has been paying any
attention at all to recent industry news.

							Thanx, Paul

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Eric W. Biederman]

"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> writes:

> On Sun, May 03, 2009 at 10:42:52PM -0700, Eric W. Biederman wrote:
>> The only reason I can see for not ultimately talking about things publicly
>> is if this is one company making shady deals with another company in which
>> case I do not see why the maintenance burden for those decision should
>> fall on the linux community as a whole.
>
> Another reason is that past experience would indicate that anything we
> say in public and and will be used against us.

Which is a fine reason to be careful what you say, and to say
reasonable things.  It is not a reason to submit a patch without
justification.

If the reason for submitting a patch is not sufficiently good to be
held to then it appears insufficient to merge the patch.

Why should the commit to a position at your urging that you aren't
willing to commit to?

Eric

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Paul E. McKenney]

On Sun, May 03, 2009 at 10:42:52PM -0700, Eric W. Biederman wrote:
> The only reason I can see for not ultimately talking about things publicly
> is if this is one company making shady deals with another company in which
> case I do not see why the maintenance burden for those decision should
> fall on the linux community as a whole.

Another reason is that past experience would indicate that anything we
say in public and and will be used against us.

							Thanx, Paul

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Eric W. Biederman]

tridge@samba.org writes:

> Hi Al,
>
>  > Practical consequences of establishing that kind of precedent (applying
>  > a patch on the grounds of nothing but vague references to possibly
>  > legal problems, with author explicitly refusing to explain exact reasons)
>  > can also be non-trivial...  And I'm not sure that it won't have legal
>  > ones as well, while we are at it.
>
> You are absolutely right. For that reason, I expect that anyone who
> does finally make the decision to include this patch, or something
> like it, will have had a long discussion with a lawyer first, and will
> fully understand the reasons for it.
>
> Meanwhile though, there is something we can do here in public, which
> is to discuss the technical merits of the proposed patch. It might be
> that you or someone else can come up with a better technical approach.
>
> I also realise that discussing the technical merits of a patch without
> first establishing the exact non-technical reasons for the patch is
> difficult, but as Hirofumi-san has shown, it is possible.

Great now we go from security theater to patent theater.
And even more it appears to be a shed painting project.

Fun to watch but no real content.

The reality is that without a clear understanding of what the bug is
it is impossible to review the code to see if it actually fixes the
bug.  So from a purely code side it is impossible to see if it the
patch does what is intended.


>From the few reports I have heard that the actual bug is not in the
linux kernel code but rather it sounds like a denial of service attack
against the implementation of http://uscode.house.gov/.  With the
attackers being able to inject a few bogus values, and cause lots of
mayhem.

Now in the linux kernel we work around lots of bugs from lots of
different sources, and this may be a place to work around someone
else's bug.  This does not appear to be a context where anyone is
concerned about a 0 day exploit, so we don't need to rush.  Further
the functionality has been the same in the same in all places for a
long time, and all of the pieces are at least in theory open to public
review.  So this should be a reasonable context for a public discussion.

The only reason I can see for not ultimately talking about things publicly
is if this is one company making shady deals with another company in which
case I do not see why the maintenance burden for those decision should
fall on the linux community as a whole.

So for the same reasons we always want a good description of the
reasons for a change in the linux kernel, to ensure we understand what
the change is for and can properly review it.  To ensure that the
submitter knows what they are talking about we need a good change
description.

My experience with special cases and running around the normal process is
that it always produces an inferior result.  This case seems no different.

So please let's treat a bug as a bug and make certain that everyone knows
what is going on, and that this isn't an attempt to foist maintenance
off someones purely local hack off onto the greater linux community.

Given the continual rate of change in the linux kernel whatever that config
option is supposed to protect will inevitably bitrot unless it is clear
what it is protecting, and someone bothers to test and verify it.

Eric

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[tridge]

Hi Al,

 > Practical consequences of establishing that kind of precedent (applying
 > a patch on the grounds of nothing but vague references to possibly
 > legal problems, with author explicitly refusing to explain exact reasons)
 > can also be non-trivial...  And I'm not sure that it won't have legal
 > ones as well, while we are at it.

You are absolutely right. For that reason, I expect that anyone who
does finally make the decision to include this patch, or something
like it, will have had a long discussion with a lawyer first, and will
fully understand the reasons for it.

Meanwhile though, there is something we can do here in public, which
is to discuss the technical merits of the proposed patch. It might be
that you or someone else can come up with a better technical approach.

I also realise that discussing the technical merits of a patch without
first establishing the exact non-technical reasons for the patch is
difficult, but as Hirofumi-san has shown, it is possible.

Cheers, Tridge

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Al Viro]

On Mon, May 04, 2009 at 08:25:05AM +1000, tridge@samba.org wrote:
> Hi Pavel,
> 
>  > Well if they are obvious, please get us someone who _can_ discuss them
>  > with us. Preferably a lawyer that can explain why the patch is
>  > neccessary.
> 
> I am trying to get that to happen, and I do realise that getting a
> lawyer to publicly explain the situation would be really
> worthwhile. Unfortunately lawyers are (mostly) very shy of making
> public statements of this type, because the legal consequences of
> making these statements can be non-trivial.

Practical consequences of establishing that kind of precedent (applying
a patch on the grounds of nothing but vague references to possibly
legal problems, with author explicitly refusing to explain exact reasons)
can also be non-trivial...  And I'm not sure that it won't have legal
ones as well, while we are at it.

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[tridge]

Hi Pavel,

 > Well if they are obvious, please get us someone who _can_ discuss them
 > with us. Preferably a lawyer that can explain why the patch is
 > neccessary.

I am trying to get that to happen, and I do realise that getting a
lawyer to publicly explain the situation would be really
worthwhile. Unfortunately lawyers are (mostly) very shy of making
public statements of this type, because the legal consequences of
making these statements can be non-trivial.

Cheers, Tridge

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Pavel Machek]

On Sat 2009-05-02 19:30:02, tridge@samba.org wrote:
> Hi Christoph,
> 
>  > At that point you shouldn't even bother to send a patch.
> 
> The non-technical reasons for this patch are available to anyone who
> cares to read any of the many news sites that discuss recent
> events. The fact that I can't discuss those reasons shouldn't preclude

Is reading /. now required part of patch reviewer's day?

You are

1) submitting the patch

2) saying that reasons for it are non-technical and obvious

3) saying that you can't tell us the reasons.

Well if they are obvious, please get us someone who _can_ discuss them
with us. Preferably a lawyer that can explain why the patch is
neccessary.
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Christoph Hellwig]

On Sat, May 02, 2009 at 07:30:02PM +1000, tridge@samba.org wrote:
> The non-technical reasons for this patch are available to anyone who
> cares to read any of the many news sites that discuss recent
> events. The fact that I can't discuss those reasons shouldn't preclude
> me from proposing a technical solution which tries to minimise the
> impact on Linux users.

Yes, the fact that you let someone else send a patch for you, refuse to
state any reason for it and when asked for it talk around the problems
is a very good reason not to bother with a patch.

If you think there is a patent problem with long file names and have
a good argument for it we should just make the reduce functionality
the default until it's settled.  If you do not have a good argument
we should drop this completely.

> I'm hoping that you and others will look at the proposed technical
> solution to the non-technical problem, and perhaps suggest better
> approaches. There are a wide variety of approaches to avoiding this
> problem, and we need to work out which, if any, should be part of the
> kernel.org releases.

Sorting out a problem starts with clearly stating what the problem is.

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[tridge]

Hi Christoph,

 > At that point you shouldn't even bother to send a patch.

The non-technical reasons for this patch are available to anyone who
cares to read any of the many news sites that discuss recent
events. The fact that I can't discuss those reasons shouldn't preclude
me from proposing a technical solution which tries to minimise the
impact on Linux users.

I'm hoping that you and others will look at the proposed technical
solution to the non-technical problem, and perhaps suggest better
approaches. There are a wide variety of approaches to avoiding this
problem, and we need to work out which, if any, should be part of the
kernel.org releases.

Cheers, Tridge

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Christoph Hellwig]

On Sat, May 02, 2009 at 07:15:02PM +1000, tridge@samba.org wrote:
> Unfortunately I am unable to discuss any of the non-technical reasons
> for why "get the VFAT out" might be a good idea in the first
> place. That is damn frustrating, but it is just how things are.

At that point you shouldn't even bother to send a patch.

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[tridge]

Hi Matthew,

 > So what's the purely technical argument for including this patch?

There is no purely technical argument for including this patch, as the
patch removes functionality without removing much code.

However, if you are willing to concede that there are good
non-technical arguments for wanting to "get the VFAT out" then
choosing the best way to achieve that is most definately a technical
decision, and that is what we can discuss here. 

Unfortunately I am unable to discuss any of the non-technical reasons
for why "get the VFAT out" might be a good idea in the first
place. That is damn frustrating, but it is just how things are.

So, on the technical front, what we need is a patch that keeps as much
functionality in Linux as possible while also giving us a high degree
of confidence that the patch will make the non-technical issues go
away.

This patch is one way to achieve that. There are certainly other
patches that would be possible, each with a different trade off in
terms of functionality loss. 

So, from a technical point of view the patch is pretty simple. When
the option is enabled you can still read all VFAT filesystems, with
any filenames (long or short). If you try to create a file with a long
filename then you get -1/ENAMETOOLONG. That means that Linux users
running a kernel with this patch enabled can plug in VFAT formatted
USB keys which have been written on windows/macosx etc systems, and
see all the files. When the Linux user wants to give a file to a
person running Windows, and they want to use a FAT based filesystem to
do it, then the Linux user has to choose a 8.3 name for the file. That
is a nuisance, but is a lot better than nothing.

Cheers, Tridge

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Christoph Hellwig]

On Fri, May 01, 2009 at 10:12:58PM -0400, Theodore Tso wrote:
> So I don't believe removing the code is the right thing to do.  I do
> believe that giving people who build and use the Linux kernel choice
> is a good thing; consider that digital cameras manufactures have
> adhered to a 8.3 filenames, which is encoded in the DCIM standard, for
> 15+ years --- and I don't believe that's an accident.  What might lead
> one company to settle and another one to fight and another to decide
> to evade the issue, may depend on many things, and may have very
> little have to do with Truth or Ethics or Morality.  Welcome to the
> law and business as practiced in our civilized society.

Still not reason to make this a config option.  There's not reason Tom
Tom can't just put a patch in to disable what they want.

Then again I have the feeling this whole thing goes deeper than people
want to make it appear.  When a patch authored by person A gets sent by
person B with a total nonsense patch description talking around the
reason why it's submitted Ccing a dozend people something is fishy and I
want this resolved first.

> (But hey, at least we don't torture people!  :-)

We don't?  Guess I missed the memo..

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Christoph Hellwig]

On Fri, May 01, 2009 at 06:37:29PM -0700, Paul E. McKenney wrote:
> Hello, Christoph!
> 
> Hmmm...  Both Tridge and Dave have Signed-off-by on the original patch,
> and Steve has Acked-by, Mingming has Cc, and Dave is on the From list
> rather than the Cc list, so I have to guess that there is a good chance
> that you are talking about me.  ;-)
> 
> However, as far as I know, none of us are lawyers, and LKML is definitely
> a technical rather than a legal forum, so we really do need to stick to
> technical topics.  I understand that this might be a bit frustrating
> to you.  On the other hand, I for one much prefer being in a forum
> restricted to technical topics than to be in those places designed to
> handle legal topics!
> 
> I suspect that this is not the answer that you were looking for, and
> I do apologize for any disappointment, but this does happen to be the
> answer that I have.

-ENOCONTENT

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Paul E. McKenney]

On Fri, May 01, 2009 at 07:59:28PM -0600, Matthew Wilcox wrote:
> On Fri, May 01, 2009 at 06:37:29PM -0700, Paul E. McKenney wrote:
> > On Fri, May 01, 2009 at 05:01:09PM -0400, Christoph Hellwig wrote:
> > > >From the complete lack of technical arguments it's pretty obvious that
> > > this seems to be some FUD fallout from the MS vs TomTom patent lawsuite.
> > > 
> > > I'm not a lawyer so I don't know how much of a threat it is.  But either
> > > the case gets shot down by showing prior art and everything is fine, or
> > > we indeed are in deep trouble and should remove it completely.  Given
> > > the Cc list on here IBM seems to have some legal opinion on it, so can
> > > we please see it and discuss what we want to with all cards on the
> > > table?
> > 
> > Hello, Christoph!
> > 
> > Hmmm...  Both Tridge and Dave have Signed-off-by on the original patch,
> > and Steve has Acked-by, Mingming has Cc, and Dave is on the From list
> > rather than the Cc list, so I have to guess that there is a good chance
> > that you are talking about me.  ;-)
> > 
> > However, as far as I know, none of us are lawyers, and LKML is definitely
> > a technical rather than a legal forum, so we really do need to stick to
> > technical topics.  I understand that this might be a bit frustrating
> > to you.  On the other hand, I for one much prefer being in a forum
> > restricted to technical topics than to be in those places designed to
> > handle legal topics!
> 
> So what's the purely technical argument for including this patch?

Pretty much what it says in the config-variable description in the patch
itself.  To recap, with some technical elaboration:

1.	It allows you to read VFAT media, mixed-case long names and all.
	Full compatibility for reading from existing media.

2.	It allows opening existing mixed-case long-named files
	both for reading and writing.

3.	For file creation, only the 8.3-format filename is permitted.
	Such a name can be stored in a single VFAT directory entry.

4.	It allows you to create files with both uppercase and lowercase
	8.3-format names, as long as the 8-character portion is either
	entirely uppercase or entirely lowercase, and as long as
	the 3-character extension is either entirely uppercase
	or entirely lowercase.  This again keeps the name confined
	to a single VFAT directory entry.

>From the original patch, with a couple additional examples added:

o	Creating FILE1234.TXT is allowed.

o	Creating FILE12345.TXT or FILE1234.TEXT is prohibited, as
	neither fits the 8.3 format.

o	Creating FILE.TXT, FILE.txt, file.TXT, and file.txt would all
	be allowed, and would create files by exactly those names.

o	Attempting to create File.TxT will give you a file named FILE.TXT.

There you have it!

							Thanx, Paul

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Steve French]

On Fri, May 1, 2009 at 8:59 PM, Matthew Wilcox <matthew@wil.cx> wrote:
> On Fri, May 01, 2009 at 06:37:29PM -0700, Paul E. McKenney wrote:
>> However, as far as I know, none of us are lawyers, and LKML is definitely
>> a technical rather than a legal forum, so we really do need to stick to
>> technical topics.  I understand that this might be a bit frustrating
>> to you.  On the other hand, I for one much prefer being in a forum
>> restricted to technical topics than to be in those places designed to
>> handle legal topics!
>
> So what's the purely technical argument for including this patch?
The strength of Tridge's approach over alternatives may be that it is clearer
to only create one name (always) and that it is relatively small.
Its weakness in my opinion is that as a sideeffect it prevents saving mixed
case file names.

There are various ways to disable (only) creating long file names, ie
to remove the ability
to create files longer than 8.3 from this module.   Tridge's approach (which
basically avoids saving the alternate name, the mixed case name) works.
I realize that there are other ways to do this with trivial #ifdefs in
namei_vfat.c (see
vfat_build_slots and vfat_create_shortname), and when I tried other approaches
they worked too, although you may prefer Tridge's approach.



-- 
Thanks,

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Theodore Tso]

On Fri, May 01, 2009 at 05:01:09PM -0400, Christoph Hellwig wrote:
> Steve, can you please stop the bullshitting?
> 
> From the complete lack of technical arguments it's pretty obvious that
> this seems to be some FUD fallout from the MS vs TomTom patent lawsuite.
> 
> I'm not a lawyer so I don't know how much of a threat it is.  But either
> the case gets shot down by showing prior art and everything is fine, or
> we indeed are in deep trouble and should remove it completely.  Given
> the Cc list on here IBM seems to have some legal opinion on it, so can
> we please see it and discuss what we want to with all cards on the
> table?

It's really not that simple.  For some of the complexities involved,
please see:

http://arstechnica.com/open-source/news/2009/04/open-invention-network-seeks-prior-art-to-burn-fat-patents.ars

http://arstechnica.com/open-source/news/2009/04/linux-foundation-says-its-time-to-ditch-microsofts-fat.ars

I personally believe that the patents are bullshit, but at the same
time, I also believe that the USPTO is underfunded, has incompetent
patent examiners (if they were competent engineers they could be
making 2 or 3 times as much money and have much better working
conditions), and they are very loath to admit that they make mistakes,
whch is just human nature, I suppose --- and also, that in our
society, you get the best justice money can buy.

Even if the patents are bullshit, some companies, especially those
that might not have the money to engage in long, extended, drawn-out
patent battles that could easily cost $10 million minimum, might
decide that it's better to evade the issue than to fight the good
fight.  If you're a small company, and you can't afford the legal
battle, or worse yet, be able to survive drop in sales caused by the
FUD generated during the lawsuit about whether or not you'll be around
to support your customers in the long-term, you make make difference
choices compared to some other larger, more secure company.

I have no trouble walking in Chinatown near the "Combat Zone" in
Boston at night; someone who is half my size and female and who has
had no martial arts training, however, might decide differently.  In
neither case is the mugger justified in doing what they are doing, but
we live in an imperfect world, where pirates can hijack ships near
Somalia even though that's also Wrong.

So I don't believe removing the code is the right thing to do.  I do
believe that giving people who build and use the Linux kernel choice
is a good thing; consider that digital cameras manufactures have
adhered to a 8.3 filenames, which is encoded in the DCIM standard, for
15+ years --- and I don't believe that's an accident.  What might lead
one company to settle and another one to fight and another to decide
to evade the issue, may depend on many things, and may have very
little have to do with Truth or Ethics or Morality.  Welcome to the
law and business as practiced in our civilized society.

(But hey, at least we don't torture people!  :-)

    		    	      	     	       - Ted

P.S.  Everything in this e-mail is my own opinion, and does not
necessarily represent the positions, strategies, or opinions of IBM or
the Linux Foundation.

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Matthew Wilcox]

On Fri, May 01, 2009 at 06:37:29PM -0700, Paul E. McKenney wrote:
> On Fri, May 01, 2009 at 05:01:09PM -0400, Christoph Hellwig wrote:
> > >From the complete lack of technical arguments it's pretty obvious that
> > this seems to be some FUD fallout from the MS vs TomTom patent lawsuite.
> > 
> > I'm not a lawyer so I don't know how much of a threat it is.  But either
> > the case gets shot down by showing prior art and everything is fine, or
> > we indeed are in deep trouble and should remove it completely.  Given
> > the Cc list on here IBM seems to have some legal opinion on it, so can
> > we please see it and discuss what we want to with all cards on the
> > table?
> 
> Hello, Christoph!
> 
> Hmmm...  Both Tridge and Dave have Signed-off-by on the original patch,
> and Steve has Acked-by, Mingming has Cc, and Dave is on the From list
> rather than the Cc list, so I have to guess that there is a good chance
> that you are talking about me.  ;-)
> 
> However, as far as I know, none of us are lawyers, and LKML is definitely
> a technical rather than a legal forum, so we really do need to stick to
> technical topics.  I understand that this might be a bit frustrating
> to you.  On the other hand, I for one much prefer being in a forum
> restricted to technical topics than to be in those places designed to
> handle legal topics!

So what's the purely technical argument for including this patch?

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Paul E. McKenney]

On Fri, May 01, 2009 at 05:01:09PM -0400, Christoph Hellwig wrote:
> On Fri, May 01, 2009 at 03:18:20PM -0500, Steve French wrote:
> > For those manufacturers who who would like to disable
> > creation of long file names, but allow reading long file names,
> > and handle FAT32 on disk format and maximum sizes, it seems
> > reasonable to give them a simple configure option for it.  It is
> > harder, and less effective, to make the corresponding change
> > to modify the mount helper and kernel code to add
> > a new mount option, because it can be bypassed trivially
> > at the command line (ie having to "force" mount to pass a "nolongfilename"
> > mount option, would be harder than a simple kernel configure option)
> 
> Steve, can you please stop the bullshitting?
> 
> >From the complete lack of technical arguments it's pretty obvious that
> this seems to be some FUD fallout from the MS vs TomTom patent lawsuite.
> 
> I'm not a lawyer so I don't know how much of a threat it is.  But either
> the case gets shot down by showing prior art and everything is fine, or
> we indeed are in deep trouble and should remove it completely.  Given
> the Cc list on here IBM seems to have some legal opinion on it, so can
> we please see it and discuss what we want to with all cards on the
> table?

Hello, Christoph!

Hmmm...  Both Tridge and Dave have Signed-off-by on the original patch,
and Steve has Acked-by, Mingming has Cc, and Dave is on the From list
rather than the Cc list, so I have to guess that there is a good chance
that you are talking about me.  ;-)

However, as far as I know, none of us are lawyers, and LKML is definitely
a technical rather than a legal forum, so we really do need to stick to
technical topics.  I understand that this might be a bit frustrating
to you.  On the other hand, I for one much prefer being in a forum
restricted to technical topics than to be in those places designed to
handle legal topics!

I suspect that this is not the answer that you were looking for, and
I do apologize for any disappointment, but this does happen to be the
answer that I have.

							Thanx, Paul

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Christoph Hellwig]

On Fri, May 01, 2009 at 03:18:20PM -0500, Steve French wrote:
> For those manufacturers who who would like to disable
> creation of long file names, but allow reading long file names,
> and handle FAT32 on disk format and maximum sizes, it seems
> reasonable to give them a simple configure option for it.  It is
> harder, and less effective, to make the corresponding change
> to modify the mount helper and kernel code to add
> a new mount option, because it can be bypassed trivially
> at the command line (ie having to "force" mount to pass a "nolongfilename"
> mount option, would be harder than a simple kernel configure option)

Steve, can you please stop the bullshitting?

>From the complete lack of technical arguments it's pretty obvious that
this seems to be some FUD fallout from the MS vs TomTom patent lawsuite.

I'm not a lawyer so I don't know how much of a threat it is.  But either
the case gets shot down by showing prior art and everything is fine, or
we indeed are in deep trouble and should remove it completely.  Given
the Cc list on here IBM seems to have some legal opinion on it, so can
we please see it and discuss what we want to with all cards on the
table?

Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Steve French]

Dave Kleikamp <shaggy@linux.vnet.ibm.com> wrote on 05/01/2009 02:09:33 PM:
> On Fri, 2009-05-01 at 22:19 +0400, Michael Tokarev wrote:
> > Dave Kleikamp wrote:
> > > On Fri, 2009-05-01 at 13:47 -0400, Christoph Hellwig wrote:
> > >> On Fri, May 01, 2009 at 12:41:29PM -0500, Dave Kleikamp wrote:
> > >>> From: Andrew Tridgell <tridge@samba.org>
> > >>> Subject: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option
> > >>>
> > >>> When this option is enabled the VFAT filesystem 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.
> > >> This doesn't make any sense as a compile time option. Might make sense
> > >> as a mount option, but I'd like to hear a rationale for it first.
> > >
> > > Some linux-based devices would be happy not to contain code to create
> > > the long name at all.
> >
> > Well, is that a rationale per se?  Which devices they are and why?
>
> Could be anything.  cameras, phones, etc.  Anything that might be
> mountable by a host computer in order to share files, or to write to a
> device that can be shared by other computers or devices.
>
> > But besides, why `msdos' filesystem is not sufficient?
> > It contains no code to create long file names and no code to
> > read such names either.
>
> An example, an mp3 player wants to read files with long mixed-case
> names, which can be manipulated on a host computer.  But it may not need
> to create files that don't fit the 8.3 syntax.
>
> Of course, msdos might be a good option for other devices.

msdos file system does not support other features that vfat does
(there are probably more than maximum volume and file size).
For those manufacturers who who would like to disable
creation of long file names, but allow reading long file names,
and handle FAT32 on disk format and maximum sizes, it seems
reasonable to give them a simple configure option for it.  It is
harder, and less effective, to make the corresponding change
to modify the mount helper and kernel code to add
a new mount option, because it can be bypassed trivially
at the command line (ie having to "force" mount to pass a "nolongfilename"
mount option, would be harder than a simple kernel configure option)

-- 
Thanks,

Steve