AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Win32/Win64 API (native code) 256-Pfadlängenbeschränkung ist in Windows 10 (1607) gefallen

256-Pfadlängenbeschränkung ist in Windows 10 (1607) gefallen

Ein Thema von Bernhard Geyer · begonnen am 4. Okt 2018 · letzter Beitrag vom 8. Nov 2018
Antwort Antwort
Seite 3 von 4     123 4   
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
34.931 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#21

AW: 256-Pfadlängenbeschränkung ist in Windows 10 (1607) gefallen

  Alt 6. Okt 2018, 17:49
Blöd ist nur, dass diese $-Freigaben versteckt sind und in den Eigenschaften des Laufwerks nicht angezeigt werden.
Drum werden viele wohl nicht wissen, dass man da was löschen könnte.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014
  Mit Zitat antworten Zitat
Benutzerbild von Dalai
Dalai

Registriert seit: 9. Apr 2006
1.237 Beiträge
 
Delphi 5 Professional
 
#22

AW: 256-Pfadlängenbeschränkung ist in Windows 10 (1607) gefallen

  Alt 6. Okt 2018, 18:45
[OT]

Die administrativen Freigaben kommen sowieso von selbst wieder:
Zitat:
---------------------------
Freigegebene Ordner
---------------------------
Diese Freigabe wurde nur für Verwaltungszwecke erstellt. Diese Freigabe wird wieder eingeblendet, wenn der Serverdienst beendet und neu gestartet wird oder wenn der Computer neu gestartet wird. Soll B$ nicht mehr freigegeben werden?
---------------------------
Ja Nein
---------------------------
Insofern muss man schon per Gruppenrichtlinien bzw. Registry rangehen, wenn man die permanent loswerden will. Es bleibt aber die Frage, warum man die Freigaben unbedingt loswerden will, wenn sowieso nur der Admin Zugang hat.

[/OT]

Grüße
Dalai
  Mit Zitat antworten Zitat
Whookie

Registriert seit: 3. Mai 2006
Ort: Graz
395 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#23

AW: 256-Pfadlängenbeschränkung ist in Windows 10 (1607) gefallen

  Alt 9. Okt 2018, 09:35
Um auf das ursprüngliche Thema zurückzukommen. Ich habe das hier auf einem Windows 2016 Server und auf Windows 10 ausprobiert.

Der Registrykey hebt die 260-Zeichengrenze nicht auf. Er muss aber gesetzt werden, damit der im Manifest vorhandene <longPathAware> - Eintrag berücksichtigt wird.
Die Powershell arbeitet zum Beispiel auf diese Weise (im Gegensatz zum Explorer) und kann dann mit überlangen Dateinamen umgehen und auch in eigenen Programmen funktioniert das dann.

Unabhängig davon funktioniert die Verwendung von \\?\.

Daher bringt der Manifest-Eintrag wohl eher längerfristig was, wer aktuell mit langen Pfaden arbeiten möchte muss wohl die \\?\ verwenden.

Für mich lasse ich aber momentan lieber die Finger davon - solange das OS keine vollständige Unterstützung bietet ist das Risiko Daten damit zu verstümmeln einfach zu groß.
Whookie

Software isn't released ... it is allowed to escape!
  Mit Zitat antworten Zitat
Benutzerbild von Assarbad
Assarbad

Registriert seit: 8. Okt 2010
Ort: Frankfurt am Main
1.165 Beiträge
 
#24

AW: 256-Pfadlängenbeschränkung ist in Windows 10 (1607) gefallen

  Alt 16. Okt 2018, 15:18
Aktuell \\FRANK-AT-WORK\$D\... womit es weniger Probleme gab, als wie mit \\?\D:\...
\\.\D$ ... sollte unter Umständen auch funktionieren. Der Punkt ist hier Platzhalter für den aktuellen Rechnernamen. Ist vielleicht etwas unkomplizierter als diesen vorab zu ermitteln.

Übrigens würde ich allen, die des Englischen mächtig sind, folgende Lektüre ans Herz legen: The Definitive Guide on Win32 to NT Path Conversion. Das erklärt einiges rund um das Thema, wenn auch nicht exakt die Frage oben. Einiges davon kann man sich dann auch näher mit meinem ntobjx oder mit WinObj von Sysinternals anschauen. Ach ja und das hier ist vielleicht auch noch sinnvoll.

Ja, der Grund warum eine Anwendung selbst (über das Manifest) kundtun sollte, daß sie lange Pfadnamen versteht, sollte klar sein. Schaut man sich Funktionen wie MSDN-Library durchsuchenGetFullPathName sind dokumentiert mit MSDN-Library durchsuchenMAX_PATH als maximal zulässiger Länge. Wenn sich also die Entwickler daran hielten, haben die auch nur das was damals MAX_PATH war reserviert. Bei dieser Funktion wäre es unproblematisch, aber ich entsinne mich, daß es Funktionen gibt, bei denen als Eingabe keine Maximallänge des Puffers vom Aufrufer mitgegeben wird und dann fehlt der aufgerufenen Funktion natürlich die Info, ob das Programm bereits mit langen Pfaden kompatibel ist oder nicht. Daher ist das Manifest eine sinnvolle Möglichkeit dem OS zu kommunizieren was Fakt ist.

Daher bringt der Manifest-Eintrag wohl eher längerfristig was, wer aktuell mit langen Pfaden arbeiten möchte muss wohl die \\?\ verwenden.
Das ist richtig.

Für mich lasse ich aber momentan lieber die Finger davon - solange das OS keine vollständige Unterstützung bietet ist das Risiko Daten damit zu verstümmeln einfach zu groß.
Kannst du das bitte nochmal erklären? Das erscheint mir auf einem Mißverständnis aufzubauen. Wenn du Unicode schon heute benutzt, kannst du sinnvollerweise schon heute davon profitieren, aber eben mit nem Präfix. Da verstümmelt dir das OS nix. Das OS unterstützt so einiges, was Win32-Programmierer üblicherweise nicht zu Gesicht bekommen (bspw. Datei-/Pfadnamen die sich nur in Groß-/Kleinschreibung unterscheiden). Mit dem Präfix bist du sozusagen näher am OS, aber der einzige Grund warum MAX_PATH früher 260 Zeichen war, ist, daß Windows 9x/Me auch unterstützt werden mußte. Und so hat man aus Kompatibilitätsgründen die Pfadlänge der Win32-Funktionen auf NT begrenzt. Viele Beschränkungen auf den NT-basierenden Systemen sind dieser dogmatischen Rückwärtskompatibilität geschuldet. Hier hätte Microsoft auch den Weg von SUS/POSIX einschlagen können und bspw. ausschließlich auf Quelltextkompatibilität setzen können. Allerdings hättest du dann für jede größere neue Windowsversion ne eigene EXE auszuliefern.

Wer hält dich davon ab einen PWideChar-Puffer immer mit \\?\ vorzubefüllen? Du kannst ja beim Aufruf der entsprechenden API-Funktionen ganz einfach diese 4 "verbrauchten" Zeichen abziehen und @lpPath[4] übergeben, oder? Ohnehin schreiben Pfade ja quasi danach als Objekte behandelt zu werden. So gesehen böte sich an die eigenen Pfadklassen einfach aufzubohren - da muß niemand tausende Quelltextstellen anpassen

Abgesehen davon ist die maximale Pfadlänge ohnehin eine eher verschwommene Angelegenheit. Die 32767 Zeichen sind Maximum und haben damit zu tun, daß MSDN-Library durchsuchenUNICODE_STRING (der gezählte Stringtyp der bspw. in der NT Native API und damit auch im Kernelmode benutzt wird) eine 16-bittige vorzeichenlose Ganzzahl als Zähler (in Bytes! nicht Zeichen!) benutzt. Davon kann man pauschal gleich schonmal die vier Zeichen für den Präfix abziehen und eins für die ASCII-Null am Ende. Und der Präfix wird normalerweise auch nochmal expandiert (siehe verlinkter Artikel oben und ntobjx).
Oliver
"... aber vertrauen Sie uns, die Physik stimmt." (Prof. Harald Lesch)

Geändert von Assarbad (16. Okt 2018 um 15:47 Uhr) Grund: Anderen Beitrag verlinkt
  Mit Zitat antworten Zitat
Benutzerbild von Memnarch
Memnarch

Registriert seit: 24. Sep 2010
736 Beiträge
 
#25

AW: 256-Pfadlängenbeschränkung ist in Windows 10 (1607) gefallen

  Alt 17. Okt 2018, 15:24
Die LongPathes gibt es schon eine ganze Weile in Windows. Einfach überall "\\?\" vorklatschen funktioniert aber nicht. Der Präfix entfernt zwar das Längenlimit von 260 Charakter, leider aber auch das Postprocessing von Pfaden. Mit entsprechenden Windowsapi-Funktionen kann man einen Pfad zuvor normalisieren. Bei uns habe ich damals extra einen Datentyp eingefügt, der dies Implizit macht. So kann man den Datentyp als Parameter für die Stellen verwenden, an denen es wichtig ist. Der Pfad selber ist aber bis dahin ein "normaler" Pfad. Generell empfiehlt es sich erst dann in den Longpath zu wandeln, wenn man auch wirklich auf Dateien zugreifen muss.
Da man Trunc nicht auf einen Integer anwenden kann, muss dieser zuerst in eine Float kopiert werden
  Mit Zitat antworten Zitat
Benutzerbild von Assarbad
Assarbad

Registriert seit: 8. Okt 2010
Ort: Frankfurt am Main
1.165 Beiträge
 
#26

AW: 256-Pfadlängenbeschränkung ist in Windows 10 (1607) gefallen

  Alt 17. Okt 2018, 20:51
Einfach überall "\\?\" vorklatschen funktioniert aber nicht. Der Präfix entfernt zwar das Längenlimit von 260 Charakter, leider aber auch das Postprocessing von Pfaden.
Was genau meinst du denn mit Postprocessing von Pfaden? Ich kenne leider nur das Expandieren auf Ebene des Object Managers. Und das funktioniert schon seit NT 3.51 tadellos mit langen Pfadnamen, denn unterhalb des Win32-Subsystems ist das die Normalität. Abgesehen davon hat man auch auf Win32-Ebene die Option \??\ als Präfix zu benutzen um bestimmte Logiken im Betriebssystem zu umgehen.

Mit entsprechenden Windowsapi-Funktionen kann man einen Pfad zuvor normalisieren.
Beispiel? Was genau meinst du hier? Umwandlung von relativen in absolute Pfade? Also im Grunde MSDN-Library durchsuchenGetFullPathName und die nativen Freunde davon, welche in dem oben verlinkten Artikel erwähnt werden?

Bei uns habe ich damals extra einen Datentyp eingefügt, der dies Implizit macht.
Und genauso macht man das auch , es sei denn es ist anderweitig in der Logik verankert.

Generell empfiehlt es sich erst dann in den Longpath zu wandeln, wenn man auch wirklich auf Dateien zugreifen muss.
Warum? Was ist denn schädlich daran generell mit langen Pfadnamen zu arbeiten? Denn wenn sich eine Empfehlung ergibt, scheint es ja einen Nachteil bei der Nutzung langer Pfadnamen zu geben. Mit ist kein Nachteil bekannt, bin daher auf die Antwort schon gespannt.

Ach ja, noch als Nachtrag zu meinem vorherigen Beitrag: shlwapi ist beispielsweise ganz schlimm in Sachen hartkodierte Beschränkung auf MAX_PATH, ebenso weitere Teile der "Shell", während bspw. WIN32_FIND_DATA wieder harmlos ist, weil es hier um ein einziges Segment des Pfads geht und eben nicht um den gesamten Pfad. Das soll an Beispielen erst einmal reichen.
Oliver
"... aber vertrauen Sie uns, die Physik stimmt." (Prof. Harald Lesch)

Geändert von Assarbad (17. Okt 2018 um 20:57 Uhr)
  Mit Zitat antworten Zitat
Whookie

Registriert seit: 3. Mai 2006
Ort: Graz
395 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#27

AW: 256-Pfadlängenbeschränkung ist in Windows 10 (1607) gefallen

  Alt 18. Okt 2018, 07:48
Für mich lasse ich aber momentan lieber die Finger davon - solange das OS keine vollständige Unterstützung bietet ist das Risiko Daten damit zu verstümmeln einfach zu groß.
Kannst du das bitte nochmal erklären? Das erscheint mir auf einem Mißverständnis aufzubauen. ...
Natürlich nicht mit der eigenen Applikation aber durch andere, die dann damit nicht zurecht kommen, dass sich die Dateien in für sie zu langen Pfaden verstecken.

Konkretes Beispiel: Eine kaum benutzte Dateizusammenstellung wurde von einem unserer Admins mit einer ältlichen Version eines Packprogrammes "in Sicherheit gebracht" und aus platzgründen vom Server gelöscht.
Nur knapp zwei Jahre später war dann doch eine Zugriff darauf nötig. Nach dem entpacken war allerdings das Erstaunen (und das Wehklagen) groß, denn im Archiv war nichts mehr drin, was tiefer als ~260 Zeichen gelegen hatte...
Whookie

Software isn't released ... it is allowed to escape!
  Mit Zitat antworten Zitat
Schokohase

Registriert seit: 17. Apr 2018
370 Beiträge
 
Delphi 10.2 Tokyo Starter
 
#28

AW: 256-Pfadlängenbeschränkung ist in Windows 10 (1607) gefallen

  Alt 18. Okt 2018, 08:39
Konkretes Beispiel: Eine kaum benutzte Dateizusammenstellung wurde von einem unserer Admins mit einer ältlichen Version eines Packprogrammes "in Sicherheit gebracht" und aus platzgründen vom Server gelöscht.
Nur knapp zwei Jahre später war dann doch eine Zugriff darauf nötig. Nach dem entpacken war allerdings das Erstaunen (und das Wehklagen) groß, denn im Archiv war nichts mehr drin, was tiefer als ~260 Zeichen gelegen hatte...
Das ist das gleiche Dilemma wie bei den ganzen Backup-Tools. Man muss ebenso regelmäßig wie das Backup selber auch die Wiederherstellbarkeit dessen überprüfen. Das kostet allerdings Zeit und Geld und wird darum gerne vernachlässigt.
  Mit Zitat antworten Zitat
Whookie

Registriert seit: 3. Mai 2006
Ort: Graz
395 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#29

AW: 256-Pfadlängenbeschränkung ist in Windows 10 (1607) gefallen

  Alt 18. Okt 2018, 09:33
Das ist das gleiche Dilemma wie bei den ganzen Backup-Tools. Man muss ebenso regelmäßig wie das Backup selber auch die Wiederherstellbarkeit dessen überprüfen. Das kostet allerdings Zeit und Geld und wird darum gerne vernachlässigt.
Ja ich habe dar schon ein paar Dinge gesehen, die zum Haare raufen sind.
Whookie

Software isn't released ... it is allowed to escape!
  Mit Zitat antworten Zitat
Benutzerbild von Assarbad
Assarbad

Registriert seit: 8. Okt 2010
Ort: Frankfurt am Main
1.165 Beiträge
 
#30

AW: 256-Pfadlängenbeschränkung ist in Windows 10 (1607) gefallen

  Alt 18. Okt 2018, 09:49
Konkretes Beispiel: Eine kaum benutzte Dateizusammenstellung wurde von einem unserer Admins mit einer ältlichen Version eines Packprogrammes "in Sicherheit gebracht" und aus platzgründen vom Server gelöscht.
Nur knapp zwei Jahre später war dann doch eine Zugriff darauf nötig. Nach dem entpacken war allerdings das Erstaunen (und das Wehklagen) groß, denn im Archiv war nichts mehr drin, was tiefer als ~260 Zeichen gelegen hatte...
Aaaaah, alles klar

Jupp, wer seine Backups nicht prüft, dem blühen derlei Probleme. Wobei ich mich dann noch fragen würde wo der Admin sein Handwerk gelernt hat. Aber wir hatten und haben derlei Admins auch in der Firma. Ich hab aus Spaß mal selbst die Stichprobe gewagt und von meinen Dateien auf dem gemeinsamen Dateiserver ein paar Dateien gelöscht. Etwa ein halbes Jahr später habe ich dann darum gebeten die Dateien wiederherzustellen. Ratet mal was ich als Antwort bekam. Erste Reaktion: "Das geht nicht!". Zweite Reaktion auf meine Rückfrage: "Man kann die Backups nur wieder komplett einspielen". Na supi. Da hat jemand bei der Auswahl des Backupsystems mitgedacht. Ich meine sogar Bandlaufwerke hatten ehemals die Möglichkeit einzelne Dateien wiederherzustellen, auch wenn es ein langwieriger Prozeß war (wegen hin- und herspulen). Aber Hauptsache ein Admin trabt treudoof jede Woche mit nem "Backup" zum Ort der (bezahlten) sicheren Verwahrung. Kreuzchen auf dem Fragebogen "Machen Sie regelmäßige Backups" kann damit auch gemacht werden. Wiederherstellung ist dann hoffentlich Problem der Nachfolger. IT 3.0!

Aber zurück zum Thema. Umso wichtiger finde ich eigentlich, daß man lange Pfade auch heute schon unterstützt und nicht erst in zwei Jahrzehnten.

Mit Junction Points kann man übrigens wunderbar auch Programme die nicht langer Pfade mächtig sind - zu einem gewissen Grad - austricksen. Besser noch, man kann mit Junction Points Pfade erzeugen die dann intern auf riesige Längen expandiert werden. Und das ganz ohne Hilfe von Präfixen.
Oliver
"... aber vertrauen Sie uns, die Physik stimmt." (Prof. Harald Lesch)
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 09:38 Uhr.
Powered by vBulletin® Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2018 by Daniel R. Wolf