DosTips.com

Hi !

According to MSDN, if we set policy for creation of file objects on format 8.3 here:
HKLM\System\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation
to value 3, I'm quote:

3: Disables 8dot3 name creation for all volumes except the system volume.

But, in real, if we will do so and restart OS, then write:

Output is only long name.
It also proves the answer of fsutil.exe:



So, 8dot3 policy works not as described in MSDN.

When I searched an answer, I reversed fsutil.exe.
I saw it check registry key:
HKLM\System\CurrentControlSet\Policies -> NtfsDisable8dot3NameCreation
(most priority)

If there is no key, the next it check:
HKLM\System\CurrentControlSet\Control\Filesystem -> NtfsDisable8dot3NameCreation

And if on these values data set to = 2, it also check special mark on service region of volume
using function DeviceIoControl (with flag FSCTL_QUERY_PERSISTENT_VOLUME_STATE).

Next, it read location of system folder throught the function GetWindowsDirectoryW.
Likely, it done for defining the letter of system drive.

I did not investigate further the logic.
Anyway, this policy works not according to MSDN manual. But why and where error ?

Dragokas wrote:So, 8dot3 policy works not as described in MSDN.

I don't see the problem based on what you quoted. SFN creation is disabled on C: because, as fsutil notes at the end of the last line, C: is a "non-system volume".

Confusing as it may be, but the "system volume" is not necessarily the one where C:\Windows is - see http://windows.microsoft.com/en-us/windows/what-are-system-boot-partitions#1TC=windows-7 for the long story.

Liviu

P.S. Off topic, but your profile "location" is seriously outdated.

foxidrive, thanks. There are really my mistake. I set that value manually without restarting instead of using fsutil.
I also tested it on XP. XP do not support value 3 and DeviceIoControl do not support query and set volume specific 8.3 flag.

So, on Win7 I see that fsutil really has a bug. On the same time OS do it right and create 8.3 names on Boot (but not a system) volume:

1) Win7 (2 volumes: G: - system, C: - boot). Real system.





2) Win7 (2 hard drives). VMware.

the "system volume" is not necessarily the one where C:\Windows is

As you can see, Microsoft do it vice versa

Thanks to all. I think the problem solved.

________
offtop. Really. I missed to write "American colony". So, if you don't like it you must do not look there.
It's just for stupid foreigners it's outdated, who think they are the smartest and understand the history better than people who live here.

Thanks for the screenshots.

It certainly looks like fsutil is misreporting the state.

Dragokas wrote:So, on Win7 I see that fsutil really has a bug. On the same time OS do it right and create 8.3 names on Boot (but not a system) volume

Confirmed. Based on the added info, in the case of "fsutil 8dot3name set 3" there appear to be:
- one bug in fsutil not recognizing the "system drive" (per "non-system drive" listed, instead), causing "8dot3name creation disabled" to be reported for all drives, even those where SFNs are still generated;
- plus one confusion in the documentation (what HKLM\System\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation calls the "system volume" seems to be what disk-manager/diskpart/etc call the "boot partition" - albeit known as %SystemDrive% to cmd ).

P.S. Off topic again, but please troll your soviet nostalgia elsewhere.