Missing alternate file name in NTFS ?

NTFSD
1

Hello, all

Could it be that a file doesn’t have the alternate (8.3) file name ?

I found that case if I have created a file name with Russian
characters (azbuka characters) on english Windows XP SP2.
If I call FindFirstFileA/FindNextFileA, the alternate file
name in the WIN32_FIND_DATA is empty. The
short file name length in FILE_BOTH_DIR_INFORMATION
is zero as well.

The file has been successfully created by my filter driver,
using my own IRP creating (well, I know that this approach
is hard and difficult to make and incompatible and whatever,
but it worked since I remember so I kept it be).

L.

2

You can disable 8.3 filenames by setting the registry entry
NtfsDisable8dot3NameCreation (in HKEY_LOCAL_MACHINE\System
\CurrentControlSet\Control\FileSystem) to 1.

I’m not sure if that’s the problem you’re seeing, but because of this you
cannot assume 8.3 filenames exist.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ladislav Zezula
Sent: Monday, May 09, 2005 8:50 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Missing alternate file name in NTFS ?

Hello, all

Could it be that a file doesn’t have the alternate (8.3) file name ?

I found that case if I have created a file name with Russian
characters (azbuka characters) on english Windows XP SP2.
If I call FindFirstFileA/FindNextFileA, the alternate file
name in the WIN32_FIND_DATA is empty. The
short file name length in FILE_BOTH_DIR_INFORMATION
is zero as well.

The file has been successfully created by my filter driver,
using my own IRP creating (well, I know that this approach
is hard and difficult to make and incompatible and whatever,
but it worked since I remember so I kept it be).

L.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Short file name creation can be disabled (via the registry), but I’ll
assume that this isn’t the case for you. Another possibility is that
there is some exception that occurs when creating this name and the
exception is trapped, but the short name is not added (short names are
added independent of the long name, so this might lead to such a
situation).

One way to test this latter case is attempt to simulate this on your own
by calling RtlGenerate8dot3Name with the file name that you used.
Another way would be to set a breakpoint in RtlGenerate8dot3Name that
you enable just before sending down this CREATE and then watch to see if
anything interesting happens (alternatively, if you don’t see it called
there might be something interesting happening inside NTFS).

I hope this helps.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ladislav Zezula
Sent: Monday, May 09, 2005 8:50 AM
To: ntfsd redirect
Subject: [ntfsd] Missing alternate file name in NTFS ?

Hello, all

Could it be that a file doesn’t have the alternate (8.3) file name ?

I found that case if I have created a file name with Russian
characters (azbuka characters) on english Windows XP SP2.
If I call FindFirstFileA/FindNextFileA, the alternate file
name in the WIN32_FIND_DATA is empty. The
short file name length in FILE_BOTH_DIR_INFORMATION
is zero as well.

The file has been successfully created by my filter driver,
using my own IRP creating (well, I know that this approach
is hard and difficult to make and incompatible and whatever,
but it worked since I remember so I kept it be).

L.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

Ken, Tony,

thank you for very fast reply.
No, the situation is not caused by registry settings,
because it is only for one particular file (I forgot to mention
it in my question).

I’ll try what Tony suggested and see what might be wrong
(Maybe it’ll be interesting to try the problem on Fastfat as well,
at least because we have source for it).

L.

5

Ladislav

I believe I have also seen with FindFirstFile/FindNextFile et al … cases
where the alternate (short) file name is empty when the long file name is
compatible as an 8.3 name. The code I have written assumes the short file
name is the same as the long file name, so to speak, in these cases, perhaps
for no particular reason.

Cheers
Lyndon

“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
> Hello, all
>
> Could it be that a file doesn’t have the alternate (8.3) file name ?
>
> I found that case if I have created a file name with Russian
> characters (azbuka characters) on english Windows XP SP2.
> If I call FindFirstFileA/FindNextFileA, the alternate file
> name in the WIN32_FIND_DATA is empty. The
> short file name length in FILE_BOTH_DIR_INFORMATION
> is zero as well.
>
> The file has been successfully created by my filter driver,
> using my own IRP creating (well, I know that this approach
> is hard and difficult to make and incompatible and whatever,
> but it worked since I remember so I kept it be).
>
> L.
>
>

6

Very strange. The 8.3 Cyrillic name must be present, and must be in OEM
(DOS 866) Cyrillic encoding.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Ladislav Zezula”
To: “Windows File Systems Devs Interest List”
Sent: Monday, May 09, 2005 4:49 PM
Subject: [ntfsd] Missing alternate file name in NTFS ?

> Hello, all
>
> Could it be that a file doesn’t have the alternate (8.3) file name ?
>
> I found that case if I have created a file name with Russian
> characters (azbuka characters) on english Windows XP SP2.
> If I call FindFirstFileA/FindNextFileA, the alternate file
> name in the WIN32_FIND_DATA is empty. The
> short file name length in FILE_BOTH_DIR_INFORMATION
> is zero as well.
>
> The file has been successfully created by my filter driver,
> using my own IRP creating (well, I know that this approach
> is hard and difficult to make and incompatible and whatever,
> but it worked since I remember so I kept it be).
>
> L.
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

7

I must be 8.3 compatible and contain Latin uppercase chars only for this.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Lyndon J Clarke”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Monday, May 09, 2005 6:37 PM
Subject: Re:[ntfsd] Missing alternate file name in NTFS ?

> Ladislav
>
> I believe I have also seen with FindFirstFile/FindNextFile et al … cases
> where the alternate (short) file name is empty when the long file name is
> compatible as an 8.3 name. The code I have written assumes the short file
> name is the same as the long file name, so to speak, in these cases, perhaps
> for no particular reason.
>
> Cheers
> Lyndon
>
> “Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
> > Hello, all
> >
> > Could it be that a file doesn’t have the alternate (8.3) file name ?
> >
> > I found that case if I have created a file name with Russian
> > characters (azbuka characters) on english Windows XP SP2.
> > If I call FindFirstFileA/FindNextFileA, the alternate file
> > name in the WIN32_FIND_DATA is empty. The
> > short file name length in FILE_BOTH_DIR_INFORMATION
> > is zero as well.
> >
> > The file has been successfully created by my filter driver,
> > using my own IRP creating (well, I know that this approach
> > is hard and difficult to make and incompatible and whatever,
> > but it worked since I remember so I kept it be).
> >
> > L.
> >
> >
>
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

8

> Very strange. The 8.3 Cyrillic name must be present,

and must be in OEM

Yes, indeed. But in this case, it isn’t.
Even NtQueryInformationFile(FilerAlternateFileNameInfo)
returns STATUS_OBJECT_NAME_NOT_FOUND (!).

BTW, the phenomenon does not depend on the
Azbuka name (it was the first conclusion). It just occurs
if the name is too long to be a DOS compatible name.
And Lyndon and Max were right, the short name must not be here
if the long name is compatible with DOS (Ntfs calls the function
NtfsIsFatNameValid for this).

The approach that Tony suggested worked - somewhere deep inside
NTFS.sys is the call of RtlGenerate8dot3Name, called
in this sequence (In the case of IRP_MJ_CREATE):

RtlGenerate8dot3Name
NtfsAddDosOnlyName
NtfsAddLink
NtfsFsdCreate

Well, I don’t want to bother you with all details, but it seems that
NTFS does not create the short file name if the file create
has been requested case sensitive. However, it seems that this
condition cannot be reached from user mode, because
even if I call NtCreateFile with OBJ_CASE_INSENSITIVE
NOT set, the file object and the stack location does not have the flag
when the IRP_MJ_CREATE arrives to my filter (not sure yet about it,
I’ll continue the analysis). It seems to me that Object manager does not
pass the case insensitivity to FSD filters and drivers.

Because the file created by my filter is created using rolling
my own IRP, the request does not pass the Object Manager.
I really wondered if this is a bug in NTFS or Object Manager
or just a feature.

L.

9

Ladislav,

I can answer at least part of your question. Refer to KB Article #
817921 (http://support.microsoft.com/default.aspx?scid=kb;en-us;817921 )
. It documents a change in the semantics of Windows XP and Windows
Server 2003 relating to case sensitivity.

Specifically it says:

By default, the Windows XP subsystems other than the Win32 subsystem are
case-preserving but not case-sensitive. However, by default, in earlier
versions of Windows the subsystems other than the Win32 subsystem are
case-sensitive.

And then notes:

To change the behavior of Windows XP after you install Windows Services
for Unix or when you use Interix 2.2, you must add the following
registry key, and then restart the computer:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session
Manager\Kernel

Value Name: ObCaseInsensitive
Data Type: REG_DWORD
Value Data: 0 (Case sensitive)

While the KB article talks about Services for Unix and Interix, this
change appears to apply universally to calls via the native API. Thus,
this is exactly what you said: the object manager does not pass in the
case sensitivity information to the file systems.

I hope this helps.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ladislav Zezula
Sent: Tuesday, May 10, 2005 7:40 AM
To: ntfsd redirect
Subject: Re: [ntfsd] Missing alternate file name in NTFS ?

Very strange. The 8.3 Cyrillic name must be present,
and must be in OEM

Yes, indeed. But in this case, it isn’t.
Even NtQueryInformationFile(FilerAlternateFileNameInfo)
returns STATUS_OBJECT_NAME_NOT_FOUND (!).

BTW, the phenomenon does not depend on the
Azbuka name (it was the first conclusion). It just occurs
if the name is too long to be a DOS compatible name.
And Lyndon and Max were right, the short name must not be here
if the long name is compatible with DOS (Ntfs calls the function
NtfsIsFatNameValid for this).

The approach that Tony suggested worked - somewhere deep inside
NTFS.sys is the call of RtlGenerate8dot3Name, called
in this sequence (In the case of IRP_MJ_CREATE):

RtlGenerate8dot3Name
NtfsAddDosOnlyName
NtfsAddLink
NtfsFsdCreate

Well, I don’t want to bother you with all details, but it seems that
NTFS does not create the short file name if the file create
has been requested case sensitive. However, it seems that this
condition cannot be reached from user mode, because
even if I call NtCreateFile with OBJ_CASE_INSENSITIVE
NOT set, the file object and the stack location does not have the flag
when the IRP_MJ_CREATE arrives to my filter (not sure yet about it,
I’ll continue the analysis). It seems to me that Object manager does not
pass the case insensitivity to FSD filters and drivers.

Because the file created by my filter is created using rolling
my own IRP, the request does not pass the Object Manager.
I really wondered if this is a bug in NTFS or Object Manager
or just a feature.

L.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

10

Tony,

thank you for the info. I didn’t know about the case insensitivity,
at least now I know that my conclusion was correct.
Anyway, adding the case insensitive flags to the call where
my driver rolls the create IRP solved the problem, the
short name is now there.

FYI, I found the problem when one of our customers
complained that after a file with “azbuka” file name
has been encrypted by our software, he was not able
to open it in Total Commander. He was able to open
it in Explorer, because Explorer is fully Unicode application and
can handle such files without problems.

As I’ve found, Total Commander uses the short name
in the case that the file name contains character(s)
from another code page than currently installed
(TC is an ANSI application). You know the rest :slight_smile:

L.

11

Total Commander has some Unicode in the latest versions. It can now display
Japanese characters even when the language is English. Earlier versions did
not do this. I requested this as I didn’t like the requirement to select a
foreign language to be able to see it.

“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
> Tony,
>
> thank you for the info. I didn’t know about the case insensitivity,
> at least now I know that my conclusion was correct.
> Anyway, adding the case insensitive flags to the call where
> my driver rolls the create IRP solved the problem, the
> short name is now there.
>
> FYI, I found the problem when one of our customers
> complained that after a file with “azbuka” file name
> has been encrypted by our software, he was not able
> to open it in Total Commander. He was able to open
> it in Explorer, because Explorer is fully Unicode application and
> can handle such files without problems.
>
> As I’ve found, Total Commander uses the short name
> in the case that the file name contains character(s)
> from another code page than currently installed
> (TC is an ANSI application). You know the rest :slight_smile:
>
> L.
>
>

12

> Total Commander has some Unicode in the latest versions. It can now

display Japanese characters even when the language is English. Earlier
versions did

Yes it can, we have the latest version here.
If you select an Unicode font (I use Microsoft Sans Serif), it can
show even the Russian (azbuka) file names. But if you check its
file actions on suchb names with FileSpy, you’ll see that it uses
the short name (if possible), or the long name converted to ANSI,
which is usually made of question marks (e.g. ???.txt).

L.