AW: 256-Pfadlängenbeschränkung ist in Windows 10 (1607) gefallen
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. :stupid: |
AW: 256-Pfadlängenbeschränkung ist in Windows 10 (1607) gefallen
[OT]
Die administrativen Freigaben kommen sowieso von selbst wieder: Zitat:
[/OT] Grüße Dalai |
AW: 256-Pfadlängenbeschränkung ist in Windows 10 (1607) gefallen
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ß. |
AW: 256-Pfadlängenbeschränkung ist in Windows 10 (1607) gefallen
Zitat:
Ü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 GetFullPathName sind dokumentiert mit MAX_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. Zitat:
Zitat:
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 :zwinker: Abgesehen davon ist die maximale Pfadlänge ohnehin eine eher verschwommene Angelegenheit. Die 32767 Zeichen sind Maximum und haben damit zu tun, daß UNICODE_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). |
AW: 256-Pfadlängenbeschränkung ist in Windows 10 (1607) gefallen
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.
|
AW: 256-Pfadlängenbeschränkung ist in Windows 10 (1607) gefallen
Zitat:
Zitat:
Zitat:
Zitat:
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. |
AW: 256-Pfadlängenbeschränkung ist in Windows 10 (1607) gefallen
Zitat:
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... |
AW: 256-Pfadlängenbeschränkung ist in Windows 10 (1607) gefallen
Zitat:
|
AW: 256-Pfadlängenbeschränkung ist in Windows 10 (1607) gefallen
Zitat:
|
AW: 256-Pfadlängenbeschränkung ist in Windows 10 (1607) gefallen
Zitat:
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! :wink: 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. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 19:07 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