[PATCH] Added CONFIG_VFAT_FS_DUALNAMES option

 > I have no objection to improve. And in this case, for this option, to
 > force the shortname= sounds reasonable.

Great!

Which varient of this would you prefer I implement? I think the two
obvious choices are:

 1) do what I did in the May patch, which is to force
    VFAT_SFN_CREATE_WINNT when the patch code triggers.

 2) force VFAT_SFN_CREATE_WINNT, but also if the name is mixed case
 within either prefix or extension (such as "Mixed.TXT") then force
 that part of the name to all lowercase. So "Mixed.TXT" would become
 "mixed.TXT" on disk.

The 2nd choice maximises compatibility with devices that don't
understand long filenames (such as Jan's camera). The first option
keeps case preservation for devices that do understand long filenames.

What do you think?

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

Hi Jan,

 > The mount(8) manpage becomes pretty ambiguous with the dualnames
 > patch.

yes, the man page will need an update certainly.

 > Making WINNT the default would cause many a `ls` output to just
 > scream at me in uppercaps because there are programs that
 > create long names with all-uppers.

well, you could also argue that having WINNT in effect does the
'correct' thing. It causes ls to display the name that is actually in
the filesystem.

I think the current default for VFAT on Linux is rather misleading. It
always displays 8.3 names as lowercase, so MAIL.dat, foo.TXT and other
combinations always display as lowercase, regardless of what the
application that created the file chose for the name.

With the winnt option the names are shown as the application that
created them chose. That is also what all current versions of Windows
do as far as I know.

yes, this means that for a digital camera card, where the camera is
always choosing all uppercase for the filenames, it can look like
'shouting' on a Linux system where lowercase is more usual. It is
however an accurate representation and maximises compatibility.

I think the current defaults were chosen a long time ago, when Win95
was more the norm, and 16 bit apps that weren't written for case
preserving filesystems were common. That era is long gone.

 > shortname really needs to be split into "shortname that is applied
 > during creation" and "shortname that is applied upon readdir".

perhaps, but I think (as you discovered!) the current VFAT options are
already too complex, and very few people set them correctly. Adding
more options to get yet more varients to the case handling behaviour
doesn't seem like a good move to me.

Other OSes with FAT implementations just choose a sane default (which
probably matches our shortname=winnt pretty closely) and the user
never gets to choose. Choice isn't always a good thing!

I should also point out that if we followed Alan's reasoning then we'd
have to actually make all these options separate filesystems, and we'd
only be able to call the shortname=winnt one "VFAT" as that is the
only one that matches Windows behaviour. The others all treat the
filesystem differently to what Windows does. (no, I'm not seriously
proposing this, just pointing out that the "it has to be a different
filesystem name" has not been always applied previously).

I wonder if Pavel still thinks that VFAT was perfect before I came
along :-)

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

[Jan Engelhardt-3]

On Friday 2009-07-03 03:11, tridge@... wrote:

>
> 1) do what I did in the May patch, which is to force
>    VFAT_SFN_CREATE_WINNT when the patch code triggers.
>
> 2) force VFAT_SFN_CREATE_WINNT, but also if the name is mixed case
> within either prefix or extension (such as "Mixed.TXT") then force
> that part of the name to all lowercase. So "Mixed.TXT" would become
> "mixed.TXT" on disk.
>
>The 2nd choice maximises compatibility with devices that don't
>understand long filenames (such as Jan's camera). The first option
>keeps case preservation for devices that do understand long filenames.

The cam does not have a problem with long filenames — as said, it works
on any to-date vanilla/distro Linux kernel, which, if I understood
mount(8) right, always create a long filename due to me using a
lowercase filename in conjunction with the default shortname=mixed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Jan Engelhardt-3]

On Friday 2009-07-03 03:26, tridge@... wrote:

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

There is no misleading in that, since VFAT is rather case-insensitive.
Certainly, lowering all 8.3 names is more appalling to the eyes than
keeping all-caps-longnames that way. I think I would even add a new
heuristic for case transformation on display to fit my personal
guidelines which would be:

  ($file, $ext) = ($filename =~ /^(.*)\.(.*)$/);
  $ext = lc $ext;
  if ($file =~ /^[A-Z]+$/) {
      $file = lc $ext;
  }

I think none of the shortcase= options does that at this time.

>I should also point out that if we followed Alan's reasoning then we'd
>have to actually make all these options separate filesystems[...]

Linux has been doing case conversion all years long so I do not think
Alan's request to make new filesystems was based solely upon
shortname=; otherwise, I suspect, it would have raised it earlier.

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

Hi Jan,

 > The cam does not have a problem with long filenames�A �1rt

That is curious. When you use a long filename (ie. a real long
filename, not a mixed case 8.3 name), if you ask the camera for
details on the photo, does it show the long filename you chose, or
does it show a 8.3 "mangled" name, like ABC~01.JPG.

 > as said, it works on any to-date vanilla/distro Linux kernel,
 > which, if I understood mount(8) right, always create a long
 > filename due to me using a lowercase filename in conjunction with
 > the default shortname=mixed.

I think you'll find it works as these kernels will be automatically
creating a "mangled" 2nd name in 8.3 format for each file with a long
name.

If you can actually see a true long filename like LongFilename.jpg on
the cameras LCD then it will warrant more investigation, and in that
case I'll try to get hold of the same model of camera and have a play
with it.

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

[Jan Engelhardt-3]

On Friday 2009-07-03 03:59, tridge@... wrote:
>
> > The cam does not have a problem with long filenames 牴
>
>That is curious. When you use a long filename (ie. a real long
>filename, not a mixed case 8.3 name), if you ask the camera for
>details on the photo,

No-no, as previously mentioned it ignores filenames not in the
format of dscf????.jpg. But if I interpret the hexdump right,
standard Linux creates a long name *anyway*, even for names
fitting in 8.3, if it's lowercase:

│00bce510 79 39 79 39 03 00 f5 5b-79 39 95 4b 00 00 00 00 |y9y9? ?[y9?K    |    
│00bce520 41 67 00 6f 00 64 00 64-00 61 00 0f 00 27 6d 00 |Ag o d d a ? 'm |    
│00bce530 6e 00 2e 00 7a 00 69 00-70 00 00 00 00 00 ff ff |n . z i p     ??|    
│00bce540 47 4f 44 44 41 4d 4e 20-5a 49 50 20 00 64 d2 20 |GODDAMN ZIP  d? |    
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[OGAWA Hirofumi]

Alan Cox <alan@...> writes:

> To my mind we need to be careful of three things
>
> - Harming the kernel to work around a potentially country specific
>   unproven problem for the benefit of a few big corporations only

My choice is to provide the option of those to users. I'm not saying to
ripping out the code for some users.

> - Getting into situations where big companies behind closed doors make
>   unaccountable decisions about a project they do not own

Now, I'm not working for any companies. I can say there is no closed
doors for me.

> - Setting trends for country specific fixups. There are a lot of
>   countries and if we keep the US happy we have to keep China happy and
>   so it goes on. Big corporations employ armies of specialists for these
>   purposes and make the gain from it. The community doesn't so it should
>   no more carry the pain of it than of long term stable releases and
>   supporting five year old vendor kernels

I'm just thinking about users. If vendors shipped the buggy code like
first buggy patch, I just thought it's more bad for our users. That's
all.

If there is community decision, I'll be really glad to follow it.

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

Hi Jan,

 > No-no, as previously mentioned it ignores filenames not in the
 > format of dscf????.jpg. But if I interpret the hexdump right,
 > standard Linux creates a long name *anyway*, even for names
 > fitting in 8.3, if it's lowercase:
 >
 > �2 "00bce510 79 39 79 39 03 00 f5 5b-79 39 95 4b 00 00 00 00 |y9y9? ?[y9?K    |    
 > �2 "00bce520 41 67 00 6f 00 64 00 64-00 61 00 0f 00 27 6d 00 |Ag o d d a ? 'm |    
 > �2 "00bce530 6e 00 2e 00 7a 00 69 00-70 00 00 00 00 00 ff ff |n . z i p     ??|    
 > �2 "00bce540 47 4f 44 44 41 4d 4e 20-5a 49 50 20 00 64 d2 20 |GODDAMN ZIP  d? |    

right, that is not unexpected. It creates both the long name and the
short name in this case as the short name is constrained to not be
case preserving, and the filesystem normally tries to be both
case-insensitive and case-preserving. As the long name has no
constraints on the case of characters it creates both so that devices
(like your camera I think) that only look at the 8.3 entries will see
a file.

That is why setting shortname=winnt is desirable when using the "no
dualnames" patch I posted. That tells Linux to behave more like what
current windows versions behave, which is to try and put it in the 8.3
entry if it can, even if it is all lowercase.

What I would like to see us do for maximum compatibility with devices
like this, while still maximising the legal safety, is to take mixed
case prefixes or suffixes that fit in 8.3 and uppercase them and set
the CASE_LOWER_BASE and CASE_LOWER_EXT bits appropriately in the flags
field, and not store a long name. That would makes us really nicely
compatible with devices like your camera, at the price of losing mixed
case preservation for 8.3 names.

It would be another departure from previous behaviour however, so I
want to get some feedback from Hirofumi-san first.

btw, if you still think your camera really is looking at the long
filename entries, then try creating a file like DsCf2000.jpg with a
unpatched kernel, mounted with shortname=winnt. That will create two
directory entries for the file, one being DSCF2000.JPG and the other
being DsCf2000.jpg.

Then view the list of photos on the LCD back panel of your
camera. Assuming it has a way to see the filename, does it display the
mixed case name DsCf2000.jpg, or does it display a non-mixed name like
dscf2000.jpg or DSCF2000.JPG.

If it displays a mixed name (ie. DsCf) then your camera can indeed
read long filename entries. If it displays a all uppercase or all
lowercase name then I think it is only capable of reading short names
from FAT filesystems. That is what I think you will find.

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

[OGAWA Hirofumi]

tridge@... writes:

> right, that is not unexpected. It creates both the long name and the
> short name in this case as the short name is constrained to not be
> case preserving, and the filesystem normally tries to be both
> case-insensitive and case-preserving. As the long name has no
> constraints on the case of characters it creates both so that devices
> (like your camera I think) that only look at the 8.3 entries will see
> a file.
>
> That is why setting shortname=winnt is desirable when using the "no
> dualnames" patch I posted. That tells Linux to behave more like what
> current windows versions behave, which is to try and put it in the 8.3
> entry if it can, even if it is all lowercase.
>
> What I would like to see us do for maximum compatibility with devices
> like this, while still maximising the legal safety, is to take mixed
> case prefixes or suffixes that fit in 8.3 and uppercase them and set
> the CASE_LOWER_BASE and CASE_LOWER_EXT bits appropriately in the flags
> field, and not store a long name. That would makes us really nicely
> compatible with devices like your camera, at the price of losing mixed
> case preservation for 8.3 names.
>
> It would be another departure from previous behaviour however, so I
> want to get some feedback from Hirofumi-san first.

I guess it would be depending on how many shortname only devices are
there though. At least for now, I'd like to keep that small.

Thanks.

> btw, if you still think your camera really is looking at the long
> filename entries, then try creating a file like DsCf2000.jpg with a
> unpatched kernel, mounted with shortname=winnt. That will create two
> directory entries for the file, one being DSCF2000.JPG and the other
> being DsCf2000.jpg.
>
> Then view the list of photos on the LCD back panel of your
> camera. Assuming it has a way to see the filename, does it display the
> mixed case name DsCf2000.jpg, or does it display a non-mixed name like
> dscf2000.jpg or DSCF2000.JPG.
>
> If it displays a mixed name (ie. DsCf) then your camera can indeed
> read long filename entries. If it displays a all uppercase or all
> lowercase name then I think it is only capable of reading short names
> from FAT filesystems. That is what I think you will find.
>
> Cheers, Tridge

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

[Jan Engelhardt-3]

On Friday 2009-07-03 05:25, tridge@... wrote:
>
>That is why setting shortname=winnt is desirable when using the "no
>dualnames" patch I posted. That tells Linux to behave more like what
>current windows versions behave, which is to try and put it in the 8.3
>entry if it can, even if it is all lowercase.

Right. That in itself is fine, but I'd still like to have readdir
return lowercase names here then. This is sort of what I seem to
remember from Windows: files only having a total-uppercase 8.3
name were still displayed as lowercase. This is why I am all for
splitting the shortcase option. (Maybe patches speak louder but
ATM I am so into Netfilter ;)

>btw, if you still think your camera really is looking at the long
>filename entries,

I toyed with the hexeditor a bit and modified the FAT entry's
filename directly. (I just hope there is not any checksum?)

 * if a filename is of the form /dscf????.jpg/i, the A210 requires
   that 8.3 names be all uppercase (even in the persence of a
   freeform long name) otherwise the OSD will (explicitly) display
   "READ ERROR".

 * if the 8.3 name is, for example, DsCE1234.jpg, the OSD seems to
   be confused and displays "00000000" as the picture index.

 => So uppercase 8.3 is a hard requirement for _any_ filename.

I also looked again at the finepix.img.bz2 I made available earlier.
It has a long entry "dscf3000.jpg", but "no shortname" (i.e. an
invalid one as generated by the patch), and that is most likely the
reason that the camera ignores this file completely.

>then try creating a file like DsCf2000.jpg with a
>unpatched kernel, mounted with shortname=winnt. That will create two
>directory entries for the file, one being DSCF2000.JPG and the other
>being DsCf2000.jpg.
>
>Then view the list of photos on the LCD back panel of your
>camera. Assuming it has a way to see the filename, does it display the
>mixed case name DsCf2000.jpg, or does it display a non-mixed name like
>dscf2000.jpg or DSCF2000.JPG.

It does not display the filename, just the index number. But the
image is present/selectable, because the 8.3 name is present and is
all-uppercase (see above).

>If it displays a mixed name (ie. DsCf) then your camera can indeed
>read long filename entries. If it displays a all uppercase or all
>lowercase name then I think it is only capable of reading short names
>from FAT filesystems. That is what I think you will find.

Capable or not — it only /needs/ 8.3 for DCIM operation :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Hi Jan,

 > Right. That in itself is fine, but I'd still like to have readdir
 > return lowercase names here then.

you are in luck!

It just so happens that this is what happens when we use the patch
that Hirofumi and I just agreed on (ie. the case handling part of my
patch from May, combined with the current patch).

I include it below. Can you please test it? It should be applied on
top of the previous patch. Note that you will not need to specify
shortname=winnt. In fact, if you don't specify any special options and
let the kernel default then you will get the behaviour you just
described.

Hirofumi-san, can you have a look at this too and see if it is how you
want to handle it? I built the patch against your fatfs-2.6 tree.

Cheers, Tridge

From 244a8ebe72288a261e68b5aea04a86793a2f11f4 Mon Sep 17 00:00:00 2001
From: Andrew Tridgell <tridge@...>
Date: Fri, 3 Jul 2009 22:15:02 +1000
Subject: [PATCH] Force case handling when dualnames are disabled for greater compatibility

When CONFIG_VFAT_FS_DUALNAMES is not set and a 8.3 name is created,
force the use of the shortname=winnt option to allow for lowercase or
uppercase prefix and extensions without using a long name.

Signed-off-by: Andrew Tridgell <tridge@...>
---
 fs/fat/namei_vfat.c |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/fs/fat/namei_vfat.c b/fs/fat/namei_vfat.c
index 894f44d..9555a46 100644
--- a/fs/fat/namei_vfat.c
+++ b/fs/fat/namei_vfat.c
@@ -317,6 +317,11 @@ 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 opts_shortname = opts->shortname;
+
+#ifndef CONFIG_VFAT_FS_DUALNAMES
+ opts_shortname = VFAT_SFN_CREATE_WINNT;
+#endif
 
  is_shortname = 1;
  INIT_SHORTNAME_INFO(&base_info);
@@ -429,9 +434,9 @@ static int vfat_create_shortname(struct inode *dir, struct nls_table *nls,
  if (vfat_find_form(dir, name_res) == 0)
  return -EEXIST;
 
- if (opts->shortname & VFAT_SFN_CREATE_WIN95) {
+ if (opts_shortname & VFAT_SFN_CREATE_WIN95) {
  return (base_info.upper && ext_info.upper);
- } else if (opts->shortname & VFAT_SFN_CREATE_WINNT) {
+ } else if (opts_shortname & VFAT_SFN_CREATE_WINNT) {
  if ((base_info.upper || base_info.lower) &&
     (ext_info.upper || ext_info.lower)) {
  if (!base_info.upper && base_info.lower)
--
1.6.0.4

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

[OGAWA Hirofumi]

tridge@... writes:

> Hirofumi-san, can you have a look at this too and see if it is how you
> want to handle it? I built the patch against your fatfs-2.6 tree.

Looks good to me. I've applied the patch + Cc:.

>>From 244a8ebe72288a261e68b5aea04a86793a2f11f4 Mon Sep 17 00:00:00 2001
> From: Andrew Tridgell <tridge@...>
> Date: Fri, 3 Jul 2009 22:15:02 +1000
> Subject: [PATCH] Force case handling when dualnames are disabled for greater compatibility

[PATCH] fat: Force case handling...

Please add "fat: " prefix at next time.

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

[Jan Engelhardt-3]

On Friday 2009-07-03 14:24, tridge@... wrote:
>Hi Jan,
>
> > Right. That in itself is fine, but I'd still like to have readdir
> > return lowercase names here then.
>
>you are in luck!

Dunno.
(It finally turns Monday...)

>I include it below. Can you please test it? It should be applied on
>top of the previous patch. Note that you will not need to specify
>shortname=winnt. In fact, if you don't specify any special options and
>let the kernel default then you will get the behaviour you just
>described.

With this extra patch:

 * "cp dscf4160.jpg dscf3010.jpg" works

 * "cp dscf4160.jpg dscF3011.jpg" does not work - i.e. cam ignores the
   file without error.
   Reason for that is that dscF3011 has an illegal 8.3 name
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Hi Jan,

 > With this extra patch:
 >
 >  * "cp dscf4160.jpg dscf3010.jpg" works

good

 >  * "cp dscf4160.jpg dscF3011.jpg" does not work - i.e. cam ignores the
 >    file without error.
 >    Reason for that is that dscF3011 has an illegal 8.3 name

yep, that's expected. I suggested a possible way of handling this to
Hirofumi-san (ie. change the case of the name), but he prefers to keep
things simple for now.

It is probably not unreasonable to say that you should not be using
mixed case names when you are putting files onto a device that doesn't
understand mixed case. The reason it worked before my patch is that
the kernel forced the case of the 8.3 name, and only retained the
mixed case for the long name.

How did things go with your mp3 players?

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

[David Newall-3]

tridge@... wrote:

> Hi Jan,
>
>  >  * "cp dscf4160.jpg dscF3011.jpg" does not work - i.e. cam ignores the
>  >    file without error.
>  >    Reason for that is that dscF3011 has an illegal 8.3 name
>
> yep, that's expected. I suggested a possible way of handling this to
> Hirofumi-san (ie. change the case of the name), but he prefers to keep
> things simple for now.
>  

Expected or not, it's a serious bug. If it doesn't canonify the
filename, it should return an error. Lying by returning success is
horridly wrong. And I might just suggest that as people are now
accustomed to typing mixed-case filenames, it's a bug that's likely to
occur more frequently than it might at first seem.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Jan Engelhardt-3]

On Monday 2009-07-06 15:05, tridge@... wrote:

>
> > With this extra patch:
> >
> >  * "cp dscf4160.jpg dscf3010.jpg" works
> >  * "cp dscf4160.jpg dscF3011.jpg" does not work - i.e. cam ignores the
> >    file without error.
> >    Reason for that is that dscF3011 has an illegal 8.3 name
>
>It is probably not unreasonable to say that you should not be using
>mixed case names when you are putting files onto a device that doesn't
>understand mixed case. The reason it worked before my patch is that
>the kernel forced the case of the 8.3 name, and only retained the
>mixed case for the long name.
>
>How did things go with your mp3 players?

Not too different from previously[1].

Entirely-lowercase fits-8-3-names work as usual, but of course are
displayed with an uppercase filename in the OSD (technically
correct, but still ick!).

Whenever a long name is created and an 8.3 name is omitted (or rather,
an invalid one is generated), files are displayed in the browser but
fail to enqueue/play.

As it stands, my two devices always want a valid 8.3 name. That in
stark conflict to your patch. And I am not going to do without long
filenames.



[1] http://osdir.com/ml/linux-kernel/2009-07/msg01314.html

Random statistic of the day about audio file's name length,
as output by R:
   Min. 1st Qu.  Median    Mean 3rd Qu.    Max.
   6.00   18.00   25.00   26.62   33.00   77.00
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Jamie Lokier]

David Newall wrote:

> tridge@... wrote:
> > Hi Jan,
> >
> >  >  * "cp dscf4160.jpg dscF3011.jpg" does not work - i.e. cam ignores the
> >  >    file without error.
> >  >    Reason for that is that dscF3011 has an illegal 8.3 name
> >
> > yep, that's expected. I suggested a possible way of handling this to
> > Hirofumi-san (ie. change the case of the name), but he prefers to keep
> > things simple for now.
> >  
>
> Expected or not, it's a serious bug. If it doesn't canonify the
> filename, it should return an error. Lying by returning success is
> horridly wrong. And I might just suggest that as people are now
> accustomed to typing mixed-case filenames, it's a bug that's likely to
> occur more frequently than it might at first seem.

It's no different from writing a long name, though, is it?

"cp dscf4160.jpg dscf3011.jpeg" would also be ignored by the
camera, because there is no corresponding 8.3 file name.

It's a bit clearer when mounted with shortname=winnt or
shortname=mixed, because then I'd expect files created by the camera
to show as upper case in Linux, and it would be obvious that you might
have to create new files for the camera that look the same as the camera's.

The current Linux default shows 8.3 short-name files in lower case
(i.e. pure FAT shows as lower case), but files created in Linux with
8.3 lower case names create a long name.  Which is bound to cause some
confusion.

I agree with tridge, shortname=winnt makes sense when dualnames are off.

Unfortunately it doesn't preserve case when creating in Linux and
reading in Windows 95/98/ME and devices with a similar implementation.

For that reason, shortname=mixed is better when dualnames are on.

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

[Jamie Lokier]

Alan Cox wrote:
> From the funnies we've had in the past with FAT my gut impression is
> there are only a few implementations out there. Psion seems to have their
> own but most of the rest behave remarkably similarly which makes me
> suspect they all licensed a tiny number of implementations (DRDOS one
> perhaps ?). If we can keep most of those devices mounted 8.3 we nicely
> sidestep the issue anyway.

From recently witnessing someone write another FAT implementation, for
an 8-bit AVR microcontroller reading SD cards, based in part on
someone elses public domain FAT implementation, fixing significant
bugs in that (including directory parsing), and then seeing it
translated from C to hand-coded AVR assembly language to save space,
with me helping teach C to the person doing it, for a commercial
product which is to be released in the next couple of months, and will
be updated with SD cards written by Linux and Windows...

From witnessing that, for one obscure product among millions, I'd
guess there are more FAT implementations than a "few".  Perhaps there
aren't many VFAT implementations, but my gut says there are quite a
lot of independently written 8.3-only FAT ones.

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

[Jamie Lokier]

tridge@... wrote:
> When CONFIG_VFAT_FS_DUALNAMES is not set and a 8.3 name is created,
> force the use of the shortname=winnt option to allow for lowercase or
> uppercase prefix and extensions without using a long name.
>
> + unsigned opts_shortname = opts->shortname;
> +
> +#ifndef CONFIG_VFAT_FS_DUALNAMES
> + opts_shortname = VFAT_SFN_CREATE_WINNT;
> +#endif

I'd prefer if it changes the shortname= default instead.

When mounting explicitly with shortname=mixed, this patch changes it
to shortname=winnt, which breaks compatibility when creating files on
Linux and reading on Windows 95/98/ME and devices with equivalent FAT
implementation.

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

But if shortname=mixed is explicitly requested, it can mean (and does
in some cases I've seen) that there's a reason long names are required
for lower-case 8.3 names.

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

Hi Jan,

 > Whenever a long name is created and an 8.3 name is omitted (or rather,
 > an invalid one is generated), files are displayed in the browser but
 > fail to enqueue/play.

Can you confirm whether without my patch, if you put a file on the
device that has a long name like ThisIsALongName.mp3 that the correct
long name is displayed in the browser on the device?

If so then it would have to be a long name capable device, and in that
case I'll have to see if I can buy one on eBay so I can have a play :-)

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