8dot3name...

[Christian @Soemtron]

Hi,

es besteht hierzugroup ja weitgehend Konsens, daß die 8.3-Dateinamen
mittlerweile überflüssig bzw. kontraproduktiv sind, weshalb man sie
abschalten sollte. Das versuche ich direkt per "Unattended Setup", was
aber nicht ganz gelingt. Auf einer Partition, auf der diese Namen z.B.
per "%SystemRoot%\System32\FSUtil.Exe" 8Dot3Name Set c: 1
deaktiviert wurden, sind sie nach Neuinstallation wieder vorhanden.
Direkt per setupcomplete.cmd deaktivieren geht zwar, aber auch ein
nachfolgendes
"%SystemRoot%\System32\FSUtil.Exe" 8Dot3Name Strip /f /s c:
hinterläßt noch zahlreiche Dateinamensleichen.

Wie macht man es richtig? Oder gibt's da auch keine Lösung wie bei
<***@point04.soemtron.de>?

cu,
Christian

PGP Key available.

[Christoph Schneegans]

Post by Christian @Soemtron
es besteht hierzugroup ja weitgehend Konsens, daß die 8.3-Dateinamen
mittlerweile überflüssig bzw. kontraproduktiv sind, weshalb man sie
abschalten sollte. Das versuche ich direkt per "Unattended Setup", was
aber nicht ganz gelingt. Auf einer Partition, auf der diese Namen z.B.
per "%SystemRoot%\System32\FSUtil.Exe" 8Dot3Name Set c: 1
deaktiviert wurden, sind sie nach Neuinstallation wieder vorhanden.

Ja, und zwar genau deshalb, weil in der install.wim 8.3-Namen enthalten
sind. Ich dachte, du kennst <https://schneegans.de/windows/no-8.3/>?

[Stefan Kanthak]

Post by Christoph Schneegans

Post by Christian @Soemtron
es besteht hierzugroup ja weitgehend Konsens, daß die 8.3-Dateinamen
mittlerweile überflüssig bzw. kontraproduktiv sind, weshalb man sie
abschalten sollte. Das versuche ich direkt per "Unattended Setup", was
aber nicht ganz gelingt. Auf einer Partition, auf der diese Namen z.B.
per "%SystemRoot%\System32\FSUtil.Exe" 8Dot3Name Set c: 1
deaktiviert wurden, sind sie nach Neuinstallation wieder vorhanden.

Ja, und zwar genau deshalb, weil in der install.wim 8.3-Namen enthalten
sind. Ich dachte, du kennst <https://schneegans.de/windows/no-8.3/>?

Ergaenzung: sobald im zur Installation ausgewaehlten Abbild (eine *.wim
enthaelt typischerweise mehrere mit den verschiedenen Editionen) ein
"kurzer" Datei- oder Verzeichnisname enthalten ist aktivieren SETUP.exe
sowie DISM.exe /Apply-Image ... die Erzeugung "kurzer" Namen im gerade
laufenden System und ggf. auf dem Zieldateisystem.

Falls ein Abbild KEINE "kurzen" Namen enthaelt, aber deren Erzeugung
weder auf dem Zieldateisystem noch im laufenden System deaktiviert ist,
dann werden sie beim Erstellen der Dateien und Verzeichnisse neu erzeugt.

JFTR: frueher war alles besser: die Abbilder von Windows 7 enthielten
KEINE "kurzen" Dateinamen, damit genuegten das o.g. FSUTIL.exe oder
ein FORMAT.com /S:DISABLE C: vor dem Starten der Installation.

Stefan

PS: von AHNUNGSLOSEN UNFAEHIGEN VOLLTROTTELN verbrochener Schrott, der
auch 27 Jahre nach Einfuehrung langer Dateinamen Kommandozeilen noch
immer ohne Anfuehrungszeichen aufruft oder in die Registry eintraegt,
obwohl die MINIMAL-Forderungen der "Designed for Windows"-Richtlinien
dies vorgeben, versagt dann klaeglich!

Folgende Kommandozeilen zeigen EINIGE Kandidaten:

FTYPE | "C:\Windows\System32\Find.exe" " %1"
FTYPE | "C:\Windows\System32\Find.exe" ":%1"
FTYPE | "C:\Windows\System32\Find.exe" /I ":%L"
FTYPE | "C:\Windows\System32\Find.exe" /I " %L"
FTYPE | "C:\Windows\System32\Find.exe" /I " C:\Program Files"
FTYPE | "C:\Windows\System32\Find.exe" /I " %ProgramFiles"
FTYPE | "C:\Windows\System32\Find.exe" /I " %CommonProgramFiles"
FTYPE | "C:\Windows\System32\Find.exe" /I "=C:\Program Files"
FTYPE | "C:\Windows\System32\Find.exe" /I "=%ProgramFiles"
FTYPE | "C:\Windows\System32\Find.exe" /I "=%CommonProgramFiles"

[Christian @Soemtron]

Post by Stefan Kanthak
Falls ein Abbild KEINE "kurzen" Namen enthaelt, aber deren
Erzeugung weder auf dem Zieldateisystem noch im laufenden System
deaktiviert ist, dann werden sie beim Erstellen der Dateien und
Verzeichnisse neu erzeugt.

Ich installiere von einem Windows PE, das in Powershell so erzeugt wurde:
Oscdimg.exe -m -o -u2 -udfver102 `
"-bootdata:2#p0,e,bc:\iso\boot\etfsboot.com#pEF,e,bc:\iso\efi\microsoft\boot\efisys.bin" `
c:\iso destination.iso

In install.wim des nach c:\iso ausgepackten Installations-Image wurden
die 8.3-Namen deaktiviert/entfernt, genau wie im laufenden System bei der
Erstellung von destination.iso.

Muß man die 8.3-Erzeugung noch irgendwo deaktivieren?

Wenn man das Zieldateisystem beim Setup automatisch erstellt, mit
(autounattend.xml):
<DiskID>0</DiskID>
<WillWipeDisk>true</WillWipeDisk>

werden dann 8.3-Namen standardmäßig erzeugt? Oder muß man die Partition
vor dem Setup anlegen, 8.3-Namen abschalten und dann mit WipeDisk-False
installieren? Beides hat bis jetzt nicht funktioniert.

cu,
Christian

PGP Key available.

[Christoph Schneegans]

Post by Christian @Soemtron
Muß man die 8.3-Erzeugung noch irgendwo deaktivieren?
Wenn man das Zieldateisystem beim Setup automatisch erstellt, mit
<DiskID>0</DiskID>
<WillWipeDisk>true</WillWipeDisk>
werden dann 8.3-Namen standardmäßig erzeugt?

Ah, es ist eine autounattend.xml im Spiel! Ich habe selber erst vor
einigen Tagen bemerkt, dass in diesem Fall die Entfernung der
8.3-Namen in der install.wim allein *nicht* ausreicht. *Zusätzlich* wird
noch ein Aufruf von fsutil.exe benötigt:

<component name="Microsoft-Windows-Setup" …>
<RunSynchronous>
<RunSynchronousCommand>
<Order>1</Order>
<Path>fsutil.exe 8dot3name set 1</Path>
</RunSynchronousCommand>
</RunSynchronous>
<DiskConfiguration>
…
<Disk>
…
<WillWipeDisk>true</WillWipeDisk>
</Disk>
</DiskConfiguration>
</component>

Damit klappt es zuverlässig und vollautomatisch.

[Christian @Soemtron]

Post by Christoph Schneegans
<RunSynchronous>
<RunSynchronousCommand>
<Order>1</Order>
<Path>fsutil.exe 8dot3name set 1</Path>
</RunSynchronousCommand>
</RunSynchronous>
Damit klappt es zuverlässig und vollautomatisch.

Kann ich bestätigen, danke. Diese elegante Lösung habe ich gesucht, aber
beim Goog^HStartpagen nicht gefunden und stundenlang vergeblich
herumgepröbelt. Es bleiben zwar noch 8.3-Namen übrig:
NTUSER~1.BLF 0x100000001523c
"c:\Users\Default\NTUSER.DAT{fd9a35db-49fe-11e9-aa2c-
248a07783950}.TM.blf"
NTUSER~1.REG 0x100000001523d
"c:\Users\Default\NTUSER.DAT{fd9a35db-49fe-11e9-aa2c-
248a07783950}.TMContainer00000000000000000001.regtrans-ms"
[...]
SPECIA~1.XML 0x100000000b998
"c:\Windows\System32\Sysprep\ActionFiles\Specialize.xml"

Die sind offenbar vor Anwendung des fsutil-Befehls entstanden und lassen
sich folgenlos löschen.

Auch zig Registry-Einträge von App-Packages werden aufgeführt, aber wohl
fälschlicherweise; da scheint fsutil lediglich auf die Tilde im
Dateinamen anzuspringen.

Wenn Du Zeit hast, könntest Du mal nach <***@point04.soemtron.de>
schauen? Tritt dieser Fehler nur hier auf?

cu,
Christian

PGP Key available.

[Christoph Schneegans]

Post by Christian @Soemtron
NTUSER~1.BLF 0x100000001523c
"c:\Users\Default\NTUSER.DAT{fd9a35db-49fe-11e9-aa2c-
248a07783950}.TM.blf"
NTUSER~1.REG 0x100000001523d
"c:\Users\Default\NTUSER.DAT{fd9a35db-49fe-11e9-aa2c-
248a07783950}.TMContainer00000000000000000001.regtrans-ms"
[...]
SPECIA~1.XML 0x100000000b998
"c:\Windows\System32\Sysprep\ActionFiles\Specialize.xml"

Für wie viele Zeilen steht denn [...] da? Zu meiner großen Überraschung
finde ich hier in einer frischen VM ebenfalls genau einen 8.3-Namen:

8dot3 Name Full Path
------------- --------------------------------------------------------------------------------------------------------------
MICROS~1.AUX "c:\Windows\assembly\…\…\Microsoft.Security.ApplicationId.PolicyManagement.PolicyEngineApi.Interop.ni.dll.aux"

Nicht ganz so überrascht bin ich, dass dieser laut

"%ProgramFiles%\7-Zip\7z.exe" l -slt "install.wim"

bereits in der install.wim existiert, obwohl ich diese mit dem
PowerShell-Skript aus https://schneegans.de/windows/no-8.3/ bearbeit
hatte:

Path = 6\Windows\assembly\…\Microsoft.Security.ApplicationId.PolicyManagement.PolicyEngineApi.Interop.ni.dll.aux
Folder = -
Size = 360
Packed Size = 314
Modified = 2019-03-19 05:45:36
Created = 2019-03-19 05:45:36
Accessed = 2019-03-19 05:45:36
Attributes = A
Method = LZX:15
Solid = -
Short Name = MICROS~1.AUX
iNode =
Links = 4
Alternate Stream = -
Alternate Streams =
SHA-1 = 957D467521652C4F403562DA07CCEA5E71687AD0
Link =
NT Security = Administrators Domains d:5 188

(Index 6 ist "Windows 10 Pro". Derselbe 8.3-Name wird auch in anderen
Abbildern gefunden, aber er ist ansonsten der einzige.)

Offenbar arbeiten mein PowerShell-Skript also nicht zuverlässig. Keine
Ahnung, woran das liegen könnte.

Post by Christian @Soemtron
Die sind offenbar vor Anwendung des fsutil-Befehls entstanden und lassen
sich folgenlos löschen.

Nein, <RunSynchronous> wird *vor* <DiskConfiguration> ausgeführt.

Post by Christian @Soemtron
Auch zig Registry-Einträge von App-Packages werden aufgeführt, aber wohl
fälschlicherweise; da scheint fsutil lediglich auf die Tilde im
Dateinamen anzuspringen.

Ja. Man muss sich schon sehr anstrengen, um in
"Microsoft.Windows.Photos_2019.18114.19418.0_neutral_~_8wekyb3d8bbwe"
einen *kurzen* Namen zu erkennen, aber die Microsoft-Entwickler schaffen
das offenbar. :-(

[Stefan Kanthak]

[...]

Post by Christoph Schneegans

Post by Christian @Soemtron
Auch zig Registry-Einträge von App-Packages werden aufgeführt, aber wohl
fälschlicherweise; da scheint fsutil lediglich auf die Tilde im
Dateinamen anzuspringen.

Ja. Man muss sich schon sehr anstrengen, um in
"Microsoft.Windows.Photos_2019.18114.19418.0_neutral_~_8wekyb3d8bbwe"
einen *kurzen* Namen zu erkennen, aber die Microsoft-Entwickler schaffen
das offenbar. :-(

Diesen Fehler haben sie vor 12 Jahren eingebaut, als sie FSUTIL.exe diese
Funktion ERSTMALS beibrachten, und trotz MEHRFACHER Hinweise sind sie
UNFAEHIG und UNWILLENS, den zu beseitigen.
ECHTE "Profis"...

Wehret den unfaehigen Schrott-Fricklern
Stefan

[Christoph Schneegans]

Zu meiner großen Überraschung finde ich hier in einer frischen VM
8dot3 Name Full Path
------------- --------------------------------------------------------------------------------------------------------------
MICROS~1.AUX "c:\Windows\assembly\…\…\Microsoft.Security.ApplicationId.PolicyManagement.PolicyEngineApi.Interop.ni.dll.aux"
Offenbar arbeiten mein PowerShell-Skript also nicht zuverlässig. Keine
Ahnung, woran das liegen könnte.

Jetzt weiß ich es. Ich hatte das Abbild in "%TEMP%\<GUID>" eingehängt.
Das führte dazu, dass der Pfad der o.g. Datei zu
"C:\Users\Administrator\AppData\Local\Temp\…\Microsoft.Security.ApplicationId.PolicyManagement.PolicyEngineApi.Interop.ni.dll.aux"
wurde und damit 261 Zeichen lang war. Wenn ich das Abbild stattdessen in
"C:\mnt" einhänge, wird der Pfad um über 70 Zeichen kürzer, und das mag
fsutil.exe offenbar lieber.

[Christian @Soemtron]

Post by Christoph Schneegans
Für wie viele Zeilen steht denn [...] da? Zu meiner großen
Überraschung finde ich hier in einer frischen VM ebenfalls genau

Es waren so 30..40. Aber mit der Änderung des Einhängepunkts entstehen
die nun gar nicht erst. :-)

cu,
Christian

PGP Key available.

[Christian @Soemtron]

Post by Christoph Schneegans

Post by Christian @Soemtron
aber nicht ganz gelingt. Auf einer Partition, auf der diese Namen
z.B. per "%SystemRoot%\System32\FSUtil.Exe" 8Dot3Name Set c: 1
deaktiviert wurden, sind sie nach Neuinstallation wieder
vorhanden.

Ja, und zwar genau deshalb, weil in der install.wim 8.3-Namen
enthalten sind. Ich dachte, du kennst
<https://schneegans.de/windows/no-8.3/>?

Ja, das habe ich natürlich gleich als erstes angewendet, hatte nur
vergessen, das zu erwähnen.

cu,
Christian

PGP Key available.

[Takvorian]

Post by Christian @Soemtron
es besteht hierzugroup ja weitgehend Konsens, daß die 8.3-Dateinamen
mittlerweile überflüssig bzw. kontraproduktiv sind, weshalb man sie
abschalten sollte.

Hier z.B. würde dann Einiges nicht mehr funktionieren. Deshalb schreibt
Microsoft dazu:
| Hinweis: Obwohl die Deaktivierung der 8.3-Dateinamenerstellung die
| Dateileistung unter Windows erhöht, können einige Anwendungen (16-Bit,
| 32-Bit oder 64-Bit) möglicherweise keine Dateien und Verzeichnisse mit
| langen Dateinamen finden.
https://support.microsoft.com/en-us/help/121007/
Könnte ggf. also Probleme bereiten und ein fühlbar schnelleres System wird
dadurch niemand bemerken. Auf Datenpartitionen werden zudem per Default
keine kurzen Dateinamen erzeugt.

[Christoph Schneegans]

Post by Takvorian
| Hinweis: Obwohl die Deaktivierung der 8.3-Dateinamenerstellung die
| Dateileistung unter Windows erhöht, können einige Anwendungen (16-Bit,
| 32-Bit oder 64-Bit) möglicherweise keine Dateien und Verzeichnisse mit
| langen Dateinamen finden.
https://support.microsoft.com/en-us/help/121007/

Fear, Uncertainty and Doubt. Anwendungen benötigen im Jahr 2020 keine
8.3-Namen, um "Dateien und Verzeichnisse" zu finden.

Wenn die 8.3-Namen aber schon in der Registry (oder in
Konfigurationsdateien o.ä.) referenziert werden, muss man sie dort
natürlich manuell ersetzen. Spricht also einiges dafür, die Erzeugung
von 8.3-Namen bereits bei der Installation abzuschalten.

Post by Takvorian
Könnte ggf. also Probleme bereiten und ein fühlbar schnelleres System wird
dadurch niemand bemerken.

Performance ist auch nicht die vorrangige Motiviation dabei.

[Stefan Kanthak]

Post by Christoph Schneegans

Post by Takvorian
| Hinweis: Obwohl die Deaktivierung der 8.3-Dateinamenerstellung die
| Dateileistung unter Windows erhöht, können einige Anwendungen (16-Bit,
| 32-Bit oder 64-Bit) möglicherweise keine Dateien und Verzeichnisse mit
| langen Dateinamen finden.
https://support.microsoft.com/en-us/help/121007/

Fear, Uncertainty and Doubt. Anwendungen benötigen im Jahr 2020 keine
8.3-Namen, um "Dateien und Verzeichnisse" zu finden.

Ersetze 2020 durch 1997: seit NT 4.0 betreibe ich von mir (mit meinen
Skripts) installierte eNTen OHNE "kurze" Dateinamen, OHNE negative
Auswirkungen auf 32- oder 64-bittige Windows-Anwendungen.
Lediglich einige DOS sowie 16-bittige Altlasten, deren Frickler fuer
Dateinamen nur 13 Oktetts kleine Puffer (statt MAX_PATH gleich 260
Oktetts grosse Puffer) missbrauchten koennen mit RICHTIGEN "langen"
Dateinamen nicht umgehen.

Ausserdem:
0. die 1995 veroeffentlichten "Designed for Windows"-Guidelines
setzen die Unterstuetzung "langer" Namen EXPLIZIT voraus;
1. fuer 64-bittige Anwendungen schreiben sie EXPLIZIT die Verwendung
"langer" statt "kurzer" Namen vor;
2. auf 64-bittigen Systemen gibt's kein NTVDM, also koennen dort
16-bittige Altherthuemer, die MOEGLICHERWEISE mit langen Namen
nicht zurecht kommen, nicht laufen.

Kurz: irgendwelche VOELLIG VERPEILTEN VOLLPFOSTEN bei Microsoft
betreiben "cargo cult", oder noch schlimmer, haben den
Produktionsprozess fuer Windows 10 NICHT im Griff!
Die Installationsabbilder fuer Windows Vista und 7 enthielten
KEINE "kurzen" Dateinamen.

Post by Christoph Schneegans
Wenn die 8.3-Namen aber schon in der Registry (oder in
Konfigurationsdateien o.ä.) referenziert werden, muss man sie dort
natürlich manuell ersetzen. Spricht also einiges dafür, die Erzeugung
von 8.3-Namen bereits bei der Installation abzuschalten.

AMEN. Wie das fuer NT 4.0, 5.x und 6.x funktioniert habe ich hierzugrupp
oft genug beschrieben.

Stefan

[Christian @Soemtron]

Post by Stefan Kanthak

Post by Christoph Schneegans
Spricht also einiges dafür, die
Erzeugung von 8.3-Namen bereits bei der Installation abzuschalten.

AMEN. Wie das fuer NT 4.0, 5.x und 6.x funktioniert habe ich
hierzugrupp oft genug beschrieben.

Das mit RunSynchronousCommand ist hier zumindest nicht angekommen. Die
Lösung mit setupcomplete.cmd ist ja etwas weniger schön.

cu,
Christian

PGP Key available.

[Takvorian]

Post by Christoph Schneegans

Post by Takvorian
| Hinweis: Obwohl die Deaktivierung der 8.3-Dateinamenerstellung die
| Dateileistung unter Windows erhöht, können einige Anwendungen (16-Bit,
| 32-Bit oder 64-Bit) möglicherweise keine Dateien und Verzeichnisse mit
| langen Dateinamen finden.
https://support.microsoft.com/en-us/help/121007/

Fear, Uncertainty and Doubt. Anwendungen benötigen im Jahr 2020 keine
8.3-Namen, um "Dateien und Verzeichnisse" zu finden.

Ich schrieb doch, dass hier dann einiges nicht mehr funktionieren würde.
Ich schrieb das nicht aus Angst, Unsicherheit und Zweifeln heraus, sondern
weil ich es genau weiß, pure Realität also. Ich weiß z.B., dass ich einen
ganzen Sack voller uralter CMD- und WSH-Skripte mit teilweise kurzen
Dateinamen erstellt habe, die heute immer noch in Verwendung sind. Die
würden dann alle versagen, müssten also vorher geändert werden. Das hebe ich
Faulpelz mir für den Tag auf, an dem Windows C: per Default nur noch ohne
kurze Dateinamen einrichtet...
Das wäre also schon mal völlig gesichertes Versagen ohne Furcht und Zweifel
- für den Rest meines Geraffels müsste ich es testen.

Post by Christoph Schneegans
Spricht also einiges dafür, die Erzeugung
von 8.3-Namen bereits bei der Installation abzuschalten.

Der Hinweis von MS ist für Fälle wie mich gedacht und das zu Recht, wie man
sieht. ;-)