Re: [RFC] FAT extension filters

[Mark Mielke <mark@mark.mielke.cc>]

On Wed, May 15, 2002 at 01:49:46PM -0400, Albert D. Cahalan wrote:
> I think the problem is in fs/fat/dir.c where
> it does:
>         for (i = 0; i < 8; i++) {
>                 /* see namei.c, msdos_format_name */
>                 if (de->name[i] == 0x05)
>                         work[i] = 0xE5;
>                 else
>                         work[i] = de->name[i];
>         }
> That should be:
>         for (i = 0; i < 8; i++) work[i] = 0xE5;
>          /* see namei.c, msdos_format_name */
>         if (*work == 0x05) *work = 0xE5;

I assume that should be:

>         for (i = 0; i < 8; i++) work[i] = de->name[i];
>          /* see namei.c, msdos_format_name */
>         if (*work == 0x05) *work = 0xE5;

The comment from msdos/namei.c reads:

  /*  0xE5 is legal as a first character, but we must substitute 0x05     */
  /*  because 0xE5 marks deleted files.  Yes, DOS really does this.       */
  /*  It seems that Microsoft hacked DOS to support non-US characters     */
  /*  after the 0xE5 character was already in use to mark deleted files.  */

A question for the long-time kernel developers who are kind enough to
spend time on a question such as this:

Should the code:

>         for (i = 0; i < 8; i++) work[i] = de->name[i];

Be written as some sort of memcpy()? I would expect the inlined
version to do two 32-bit copies, or one 64-bit copy operation for
64-bit platforms for the above piece of code. Is much of the code
written as the above? Or is effort made to try and inline it
in some better architecture-specific way?

mark

-- 
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/