Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Win32/Win64 API (native code) (https://www.delphipraxis.net/17-win32-win64-api-native-code/)
-   -   Länge Dateiname/Pfade (https://www.delphipraxis.net/202711-laenge-dateiname-pfade.html)

MicMic 30. Nov 2019 12:27

Länge Dateiname/Pfade
 
Hallo,

ich lese:
"In Windows 10, Version 1607, wurden die MAX_PATH-Einschränkungen aus den üblichen Win32-Datei- und Verzeichnisfunktionen entfernt."
Was man jedoch Windows über einen Registry-Schlüssel noch mitteilen muss (LongPathsEnabled).

Steht denn danach in MAX_PATH ein höherer Wert (sicherlich nicht) oder wie kann man das verstehen?

So ganz bin ich mit dem Thema sowieso nicht durch. Oft gibt man ja z.B. "\\?\" mit an. (z.B. bei FindFirstFileW). Aber ich glaube verstanden zu haben, dass ein einzelner Ordner (oder Dateiname) immer noch nur max. 255 (256/260?) Zeichen lang sein darf. Aber was möglich ist, wäre die komplette Pfadangabe zu vergrößern. Also Beispiel: "C:\Ordnermit250\Ordnermit200\Ordnermit255\Dateina memit255zeichen" und wenn man "\\?\" mit angibt, wäre man auf der sicheren Seite? Jetzt mit oder ohne LongPathsEnabled?

In MAX_PATH steht bei mir 260. Warum liest man manchmal 255/256 (0-255=256), also im Grunde ein ShortString?

Jedenfalls nutze ich WIN32_FIND_DATAW und u.a. hole ich mir den Dateinamen aus "cFileName[MAX_PATH]" heraus. Eigentlich gehört das auch zu den üblichen Win32-Datei- und Verzeichnisfunktionen. Was wurde denn nun entfernt mit den Registry Eintrag für LongPathsEnabled?

Und wie lang darf denn nun was und wie sein? :) Da liest man nämlich auch verschiedenes. Was mich auch interessieren würde, ob es hier ein Praxis-Beispiel für eine Ordner-Struktur von sagen wir mal 60000 Zeichen gibt? Oder ich bin mal nicht so hart. Sagen wir mal 10000 Zeichen. :)

DieDolly 30. Nov 2019 12:29

AW: Länge Dateiname/Pfade
 
Zitat:

Aber was möglich ist, wäre die komplette Pfadangabe zu vergrößern. Also Beispiel: "C:\Ordnermit250\Ordnermit200\Ordnermit255\Dat eina memit255zeichen" und wenn man "\\?\" mit angibt, wäre man auf der sicheren Seite?
Ja richtig. Mache ich seit Windows 7 so und funktioniert immer wenn man den Prefix davor setzt.

Dalai 30. Nov 2019 14:00

AW: Länge Dateiname/Pfade
 
Die Aufhebung dieser Einschränkung hat ohne Anpassungen der eigenen Anwendung keinerlei Auswirkungen. Man muss mindestens das Manifest der eigenen Anwendung um eine weitere Angabe ergänzen (longPathAware). Deswegen schreibt MS auch:
Zitat:

To enable the new long path behavior, both of the following conditions must be met:

Die Benutzung der Pfade mit Long Path Prefix \\?\ funktioniert davon unahängig, und auch in älteren Windows-Versionen (wahrscheinlich ab Win2k).

Grüße
Dalai

MicMic 30. Nov 2019 21:55

AW: Länge Dateiname/Pfade
 
Ich habe mal getestet, weil ich erst mal verstehen will, wie es die ganze Zeit so ist.

Dateitest:

Maximal Dateinamenlänge im Hauptverzeichnis C (255 Zeichen)
+ C:\ (3 Zeichen) + NULL-Zeichen (1 Zeichen)
= 259 Zeichen
Warum nicht 260 (MAX_PATH) ?

Maximal Dateinamenlänge im Verzeichnis C:\Test (251 Zeichen)
+ C:\Test\ (8 Zeichen) + NULL-Zeichen (1 Zeichen)
= 260 Zeichen (wäre MAX_PATH)

Maximal Dateinamenlänge im Verzeichnis C:\Test\Test (246 Zeichen)
+ C:\Test\Test\ (13 Zeichen) + NULL-Zeichen (1 Zeichen)
= 260 Zeichen (wäre MAX_PATH)


Ordnertest:

Maximale Ordnerlänge im Hauptverzeichnis C (244 Zeichen)
+ C:\ (3 Zeichen) + NULL-Zeichen (1 Zeichen)
+ 12 Zeichen (8+3 Dateiname + Punkt) für einen möglichen Dateinamen im Ordner
= 260 Zeichen (wäre MAX_PATH)

Maximale Ordnerlänge im Verzeichnis C:\Test (239 Zeichen)
+ C:\Test\ (8 Zeichen) + NULL-Zeichen (1 Zeichen)
+ 12 Zeichen (8+3 Dateiname + Punkt) für einen möglichen Dateinamen im Ordner
= 260 Zeichen (wäre MAX_PATH)

Maximale Ordnerlänge im Hauptverzeichnis C:\Test\Test (234 Zeichen)
+ C:\Test\Test\ (13 Zeichen) + NULL-Zeichen (1 Zeichen)
+ 12 Zeichen (8+3 Dateiname + Punkt) für einen möglichen Dateinamen im Ordner
= 260 Zeichen (wäre MAX_PATH)

Also der erste Test im Hauptverzeichnis ergibt nicht 260. Was ist hier falsch? Weiterhin überlege ich über das NULL-Zeichen nach. Die Ordnerlänge müsste doch jeweils um 1 Zeichen weniger sein, weil ein möglicher 8+3 Dateiname (in früheren Zeiten die maximale Länge) auch ein NULL-Zeichen haben muss. Also nicht 12, sondern 13 Zeichen. Zumindest für das API-Interne Zeugs.

Dalai 1. Dez 2019 01:27

AW: Länge Dateiname/Pfade
 
Es gibt einen Unterschied zwischen maximaler Pfadlänge (=MAX_PATH) und maximaler Länge eines einzelnen Dateinamens (=255 bei NTFS). Einen Pfad aus mehreren Dateinamen maximaler Länge kann man nur mit dem Long Path Prefix \\?\ benutzen (oder ab Windows 1607, wenn die beiden genannten Bedingungen erfüllt sind).

Grüße
Dalai

MicMic 1. Dez 2019 02:31

AW: Länge Dateiname/Pfade
 
Also das mit dem "\\?\" ist mir ja bekannt. Jedoch habe ich es noch nicht überall im Einsatz (beim Programmieren).

Gehen wir die Sache noch mal durch :)

Nummer 1:
Obige Rechnung stimmt. Also rechnerisch würde unter C:\ eigentlich 256 Zeichen für ein Dateiname gehen (weil's 260 ergibt), jedoch sagt NTFS, bei 255 ist Schluss
Richtig?

Nummer 2:
Ohne diesem Registry Eintrag (LongPathsEnabled=1) funktioniert's so wie in meiner Beispielrechnung? Um So mehr Unterverzeichnisse, um so kürzer dann
natürlich die Dateinamen und auch die Ordnernamen.
Richtig?

Nummer 3:
Aber in der Programmierung mit dem Prefix "\\?\" kann man Dateien (ob nun in Hauptverzeichnis oder in Unterverzeichnissen) oder aber auch Ordner (siehe Nummer 5)
mit maximal 255 Zeichen nutzen. Auch wenn "LongPathsEnabled" auf 0 steht. Wenn man es richtig mit dem Prefix und den API Funktionen umsetzt, also dann auch
kopieren/verschieben/löschen.
Richtig?

Nummer 4:
Mein CMD-Test ergab eben, mit "LongPathsEnabled=1", dass ich in jedem Unterverzeichnis maximal 255 Zeichen für ein Dateiname nutzen kann.
Richtig?

Nummer 5:
Mein CMD-Test ergab eben, mit "LongPathsEnabled=1", dass ich auch für Ordner maximal 255 Zeichen nutzen kann. Ebenfalls egal, ob im Hauptverzeichnis oder in Unterverzeichnissen.
Richtig?

Nummer 6:
Wie war das mit FAT32?
Da müsste es doch so wie bei Nummer 2 gehen.
Richtig?

Dalai 1. Dez 2019 14:20

AW: Länge Dateiname/Pfade
 
Zitat:

Zitat von MicMic (Beitrag 1452519)
Obige Rechnung stimmt. Also rechnerisch würde unter C:\ eigentlich 256 Zeichen für ein Dateiname gehen (weil's 260 ergibt), jedoch sagt NTFS, bei 255 ist Schluss
Richtig?

Jep.

Zitat:

Ohne diesem Registry Eintrag (LongPathsEnabled=1) funktioniert's so wie in meiner Beispielrechnung? Um So mehr Unterverzeichnisse, um so kürzer dann
natürlich die Dateinamen und auch die Ordnernamen.
Richtig?
Je länger der absolute Pfad, desto kürzer müssen dessen einzelne Teile sein, um das MAX_PATH Limit nicht zu überschreiten. Korrekt.

Zitat:

Aber in der Programmierung mit dem Prefix "\\?\" kann man Dateien (ob nun in Hauptverzeichnis oder in Unterverzeichnissen) oder aber auch Ordner (siehe Nummer 5)
mit maximal 255 Zeichen nutzen.
Wikipedia sagt, dass für NTFS das Limit eines einzelnen Dateinamen 255 Unicode-Zeichen ist:
Zitat:

Max. filename length: 255 UTF-16 code units
. Daran wird auch der Long Path Prefix nichts ändern. Relevant wird dieser erst, wenn es um die Länge des absoluten Pfades geht.

Zitat:

Wenn man es richtig mit dem Prefix und den API Funktionen umsetzt, also dann auch
kopieren/verschieben/löschen.
Richtig?
Ja. Wobei man beachten muss, dass IIRC nicht alle Windows API-Funktionen dieses Prefix unterstützen. CopyFileEx gehört aber in jedem Fall dazu.

Zitat:

Mein CMD-Test ergab eben, mit "LongPathsEnabled=1", dass ich in jedem Unterverzeichnis maximal 255 Zeichen für ein Dateiname nutzen kann.
Richtig?
Das wird wohl so sein. Wie gesagt: MS schreibt in dem von mir verlinkten Artikel nur etwas von der Aufhebung des MAX_PATH Limits (unter bestimmten Voraussetzungen). Das Limit der Einzelteile bleibt aber bestehen, weil die vom darunterliegenden Dateisystem diktiert werden.

Zitat:

Mein CMD-Test ergab eben, mit "LongPathsEnabled=1", dass ich auch für Ordner maximal 255 Zeichen nutzen kann. Ebenfalls egal, ob im Hauptverzeichnis oder in Unterverzeichnissen.
Richtig?
Nunja, ein Verzeichnis ist eben auch nur eine Datei mit einem zusätzlichen Attribut. Siehe WIN32_FIND_DATA-Struktur (FILE_ATTRIBUTE_DIRECTORY).

Zitat:

Wie war das mit FAT32?
Da müsste es doch so wie bei Nummer 2 gehen.
Richtig?
Wikipedia sagt:
Zitat:

Max. filename length: 8.3 filename, or 255 UCS-2 characters when using LFN
LFN = Long File Name, UCS-2 ist mehr oder weniger Unicode. Also gilt für FAT32 dasselbe, wobei wahrscheinlich MAX_PATH trotzdem nicht überschritten werden kann. Aber das weiß ich nicht, und spielt in der Realität wohl auch eine sehr untergeordnete Rolle.

Grüße
Dalai

MicMic 1. Dez 2019 20:26

AW: Länge Dateiname/Pfade
 
Da habe ich wohl jetzt die Prüfung bestanden :)
Danke für die Antwort
Zitat:

Zitat:

Mein CMD-Test ergab eben, mit "LongPathsEnabled=1", dass ich auch für Ordner maximal 255 Zeichen nutzen kann. Ebenfalls egal, ob im Hauptverzeichnis oder in Unterverzeichnissen.
Richtig?
Nunja, ein Verzeichnis ist eben auch nur eine Datei mit einem zusätzlichen Attribut. Siehe WIN32_FIND_DATA-Struktur (FILE_ATTRIBUTE_DIRECTORY).
Wird wohl jetzt so sein. Also mit LongPathsEnabled=1 bzw. mit dem Prefix "\\?\".
Die frühere Variante ergabt bei meinen Tests ja, dass bei Ordnern noch etwas abgezogen wird, damit ein möglicher 8+3 Dateiname noch reinpassen kann. Was ja auch Sinn macht.

Jetzt habe ich wenigstens Durchblick erlangen *lach*
Also Dankeschön

DieDolly 1. Dez 2019 20:32

AW: Länge Dateiname/Pfade
 
Falls du in Zukunft irgendwann ein Programm schreibst welches in der Registzry rumfummelt und LongPathsEnabled umschreibt, würde ich mir vorher die Erlaubnis vom Nutzer einholen.

MicMic 1. Dez 2019 21:29

AW: Länge Dateiname/Pfade
 
Zitat:

Zitat von DieDolly (Beitrag 1452539)
Falls du in Zukunft irgendwann ein Programm schreibst welches in der Registzry rumfummelt und LongPathsEnabled umschreibt, würde ich mir vorher die Erlaubnis vom Nutzer einholen.

Nein, wieso? Ich wollt nur ganz klar verstehen, wie das nun läuft mit Dateinamenlängen usw.
So kann man evtl. Fehler abfangen bzw. diese besser identifizieren. Gerade hier sind Errorcodes nicht immer so, wie man sich das wünschen würde.

DieDolly 1. Dez 2019 21:32

AW: Länge Dateiname/Pfade
 
Zitat:

würde ich mir vorher die Erlaubnis vom Nutzer einholen.
Zitat:

Nein, wieso?
Weil man sowas nicht macht und ungefragt Systemeinstellungen ändert.

MicMic 1. Dez 2019 21:46

AW: Länge Dateiname/Pfade
 
Ich meine mit "Nein, wieso?" dass ich hier nicht in der Registry herum schreibe bzw. sie ändere :)

DieDolly 1. Dez 2019 21:49

AW: Länge Dateiname/Pfade
 
Typisches Missverständnis :thumb:
Um so besser

Luckie 2. Dez 2019 08:04

AW: Länge Dateiname/Pfade
 
Also ich halte es so. So bald ich mir die Frage stellen muss, ob etwas reicht. Also ob so lange Dateipfade möglich sind oder ob 32.000 Einträge in eine Listbox passen, dann sage ich mir, dass was mit meinem Konzept nicht stimmt. Denn was will der Benutzer mit 32.000 Einträgen in einer Listbox zum Beispiel? Deswegen sind solche Fragen für mich eher von theoretischer Bedeutung, spielen für mich in der Praxis eher eine untergeordnete Rolle.

himitsu 2. Dez 2019 17:14

AW: Länge Dateiname/Pfade
 
Zitat:

Zitat von MicMic (Beitrag 1452499)
In MAX_PATH steht bei mir 260. Warum liest man manchmal 255/256 (0-255=256), also im Grunde ein ShortString?

256 Zeichen für den Pfad im Dateisystemtreiber,
plus die abschließende #0 und plus der Datenträger (z.B. "X:\")
3 + 256 + 1 = 260

In Windows 10 soll es nun überall keine Grenze mehr geben. (stimmt leider nicht ganz)
Also theoretisch könnte man nun das MAX_PATH vergessen, denn Windows 7 stirbt in einem Monat aus, Windows 8 nutzt niemand freiwillig und somit hätte sich quasi das Problem von selbst erledigt.

Voraussetzung: Es muß im System aktiviert sein und in jeder Anwendung muß es auch extra nochmal freigegeben sein.
https://docs.microsoft.com/en-us/win.../naming-a-file
https://mspoweruser.com/ntfs-260-character-windows-10/ (ist nun auch die der Release drin)


Zitat:

Zitat von Dalai (Beitrag 1452518)
Es gibt einen Unterschied zwischen maximaler Pfadlänge ...

Vergiss nicht die Junctions und Translations, da kommt es drauf an, was letztendlich im Dateisystem ankommt, und nicht wie es im Explorer aussieht.
Und für einen lesenden Zugriff auf den Pfad, könnte man eventuell noch den Umweg über die kurzen 8.3-Namen gehen.
(schreibend = Datei/verzeichnis erstellen, die es vorher nicht gab)

DieDolly 2. Dez 2019 17:19

AW: Länge Dateiname/Pfade
 
Ich habe zwar eine eigene Manifestdatei als Resource und die wird auch eingebunden, aber unter Projektoptionen Manifest steht die Option auf Automatisch erzeugen.

Welche wird denn jetzt benutzt? Meine oder die von Delphi? Beide?

himitsu 2. Dez 2019 17:23

AW: Länge Dateiname/Pfade
 
Die, welche zuerst gelinkt wird. (was zuerst beim Compilieren im Code gefunden wurde)

Sollte sich bei Konflikten dann auch was im Buildlog finden lassen.
http://docwiki.embarcadero.com/RADSt...5s%27_(Delphi)
http://docwiki.embarcadero.com/RADSt..._%25d_(Delphi)
bzw.
http://docwiki.embarcadero.com/RADSt...arded_(Delphi)

DieDolly 2. Dez 2019 17:25

AW: Länge Dateiname/Pfade
 
Wo kommt das denn rein?

Hier
Code:
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application xmlns="urn:schemas-microsoft-com:asm.v3">
      <windowsSettings xmlns:ws2="https://schemas.microsoft.com/SMI/2016/WindowsSettings">
        <ws2:longPathAware>true</ws2:longPathAware>
      </windowsSettings>

      <!-- Windows 10 -->
      <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>

      <!-- Windows 8.1 -->
      <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>

      <!-- Windows 8 -->
      <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>

      <!-- Windows 7 -->
      <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>

      <!-- Windows Vista -->
      <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
    </application>
  </compatibility>
Oder hier
Code:
<asmv3:application>
  <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
    <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2</dpiAwareness>
    <dpiAware>True</dpiAware>
  </asmv3:windowsSettings>
</asmv3:application>
Sollte man vielleicht einfach das Standard Delphi Manifest kopieren und erweitern? Ganz ehrlich, ich habe mittlerweile keine Ahnung mehr, ob Windows mein Manifest nutzt oder das von elphi.
Laut Resource Hacker sin beide drin.
Code:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
  <asmv3:application>
    <asmv3:windowsSettings>
      <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true/pm</dpiAware>
      <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2</dpiAwareness>
    </asmv3:windowsSettings>
  </asmv3:application>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity
        type="win32"
        name="Microsoft.Windows.Common-Controls"
        version="6.0.0.0"
        publicKeyToken="6595b64144ccf1df"
        language="*"
        processorArchitecture="*"/>
    </dependentAssembly>
  </dependency>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel
          level="asInvoker"
          uiAccess="false"
        />
      </requestedPrivileges>
    </security>
  </trustInfo>
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
   <application>
      <!--The ID below indicates app support for Windows Vista -->
      <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
      <!--The ID below indicates app support for Windows 7 -->
      <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
      <!--The ID below indicates app support for Windows 8 -->
      <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
      <!--The ID below indicates app support for Windows 8.1 -->
      <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
      <!--The ID below indicates app support for Windows 10 -->
      <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>         
   </application>
</compatibility>
</assembly>

Luckie 2. Dez 2019 18:11

AW: Länge Dateiname/Pfade
 
Bitte mach einen neuen Thread auf für ein neues Problem mit dem Manifest.

MicMic 2. Dez 2019 20:35

AW: Länge Dateiname/Pfade
 
Zitat:

Zitat von himitsu
Zitat:

Zitat von MicMic
In MAX_PATH steht bei mir 260. Warum liest man manchmal 255/256 (0-255=256), also im Grunde ein ShortString?

256 Zeichen für den Pfad im Dateisystemtreiber,
plus die abschließende #0 und plus der Datenträger (z.B. "X:\")
3 + 256 + 1 = 260

Ich hatte das ja getestet. Beitrag 4 und (6 als Abschluss) in diesem Thread.
Gehen nämlich nur 255. Aber irgendwo las ich mal, dass jemand mit irgendeinem Programm ein Dateiname erstellt hat, der weit mehr als 260 Zeichen hatte. Aber das habe ich nicht weiter verfolgt.

Zitat:

Zitat von Luckie
Also ich halte es so. So bald ich mir die Frage stellen muss, ob etwas reicht. Also ob so lange Dateipfade möglich sind oder ob 32.000 Einträge in eine Listbox passen, dann sage ich mir, dass was mit meinem Konzept nicht stimmt. Denn was will der Benutzer mit 32.000 Einträgen in einer Listbox zum Beispiel? Deswegen sind solche Fragen für mich eher von theoretischer Bedeutung, spielen für mich in der Praxis eher eine untergeordnete Rolle.

Das Konzept des Anwenders könnte man in Frage stellen. Mein Programm allerdings sollte funktionieren und nicht gleich einfrieren/abstürzen nur weil ich mich um manches nicht gekümmert habe. Deswegen interessiere ich mich auch für ein Verzeichnis mit hunderttausend Dateien... um es einfach mal durchzutesten, ein Funktionsabschnitt besser optimieren zu können usw. Natürlich bombardiere ich den Anwender nicht mit irgendwelchen Mega-Daten und lasse ihm 5 Minuten scrollen :)


Alle Zeitangaben in WEZ +1. Es ist jetzt 01:28 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz