Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Windows 10 Pfadlänge
278 views
Skip to first unread message
Jürgen Meyer
Dec 10, 2016, 4:30:10 PM12/10/16
to
Auf
https://www.deskmodder.de/blog/2016/05/28/windows-10-laengenbegrenzung-von-260-zeichen-kann-nun-aufgehoben-werden/
gibt es den obigen Beitrag.
Ich bin mir der Problematik mit überlangen Pfaden bewusst
Das ist also nicht die Frage
Meine Frage ist aber:
Wie lang darf der Pfad denn nun werden?
Dazu konnte ich bisher nichts finden
Gruß
Jürgen
https://www.deskmodder.de/blog/2016/05/28/windows-10-laengenbegrenzung-von-260-zeichen-kann-nun-aufgehoben-werden/
gibt es den obigen Beitrag.
Ich bin mir der Problematik mit überlangen Pfaden bewusst
Das ist also nicht die Frage
Meine Frage ist aber:
Wie lang darf der Pfad denn nun werden?
Dazu konnte ich bisher nichts finden
Gruß
Jürgen
Claus Reibenstein
Dec 10, 2016, 4:46:23 PM12/10/16
to
Jürgen Meyer schrieb am 10.12.2016 um 22:30:
> Auf
> https://www.deskmodder.de/blog/2016/05/28/windows-10-laengenbegrenzung-von-260-zeichen-kann-nun-aufgehoben-werden/
> gibt es den obigen Beitrag.
Der bereits über ein halbes Jahr alt ist.
> Auf
> https://www.deskmodder.de/blog/2016/05/28/windows-10-laengenbegrenzung-von-260-zeichen-kann-nun-aufgehoben-werden/
> gibt es den obigen Beitrag.
> Ich bin mir der Problematik mit überlangen Pfaden bewusst
ist. Eigentlich dachte ich, dass das schon längst behoben wäre.
> Das ist also nicht die Frage
> Meine Frage ist aber:
> Wie lang darf der Pfad denn nun werden?
Obergrenze. Laut dem von Dir verlinkten Artikel gibt es die aber doch
noch. Was stimmt denn nun?
Es ist schon merkwürdig und manchmal auch ziemlich ärgerlich, mit was
für unsinnigen Kleinigkeiten man sich unter Windows auseinandersetzen
muss. Von Linux & Co kenne ich dieses Problem nicht.
Gruß
Claus
Stefan Kanthak
Dec 10, 2016, 5:13:13 PM12/10/16
to
"Jürgen Meyer" <juergen....@gmx.de> schrieb:
> Auf
[ Link zu Schmuddelseiten entsorgt]
> gibt es den obigen Beitrag.
AUTSCH!
Dokumentation und Aenderungshinweise gibt's beim Hersteller des von Dir
missbrauchten Systems:
<https://msdn.microsoft.com/en-us/library/aa365247.aspx>
<https://msdn.microsoft.com/en-us/windows/uwp/whats-new/windows-10-version-1607>
> Ich bin mir der Problematik mit überlangen Pfaden bewusst
Wirklich?
> Das ist also nicht die Frage
> Meine Frage ist aber:
> Wie lang darf der Pfad denn nun werden?
Seit eNTe, also erst GAAANZ kurzen 23 Jahren:
(USHORT_MAX + 1) * sizeof(CHAR) / sizeof(WCHAR) - 1
Siehe <https://msdn.microsoft.com/en-us/library/aa380518.aspx>
oder <https://msdn.microsoft.com/en-us/library/ff564879.aspx>
> Dazu konnte ich bisher nichts finden
Ach?
Wie lebt sich's so, 23 Jahre unter'm Stein?
Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
> Auf
[ Link zu Schmuddelseiten entsorgt]
> gibt es den obigen Beitrag.
Dokumentation und Aenderungshinweise gibt's beim Hersteller des von Dir
missbrauchten Systems:
<https://msdn.microsoft.com/en-us/library/aa365247.aspx>
<https://msdn.microsoft.com/en-us/windows/uwp/whats-new/windows-10-version-1607>
> Ich bin mir der Problematik mit überlangen Pfaden bewusst
> Das ist also nicht die Frage
> Meine Frage ist aber:
> Wie lang darf der Pfad denn nun werden?
(USHORT_MAX + 1) * sizeof(CHAR) / sizeof(WCHAR) - 1
Siehe <https://msdn.microsoft.com/en-us/library/aa380518.aspx>
oder <https://msdn.microsoft.com/en-us/library/ff564879.aspx>
> Dazu konnte ich bisher nichts finden
Wie lebt sich's so, 23 Jahre unter'm Stein?
Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Jürgen Meyer
Dec 10, 2016, 5:13:23 PM12/10/16
to
>> Ich bin mir der Problematik mit überlangen Pfaden bewusst
>
>Wobei es mich wundert, dass das unter Windows 10 immer noch ein Problem
>ist. Eigentlich dachte ich, dass das schon längst behoben wäre.
Nicht Windows 10 ist das Problem.
>
>Wobei es mich wundert, dass das unter Windows 10 immer noch ein Problem
>ist. Eigentlich dachte ich, dass das schon längst behoben wäre.
Es sind die Anwenderprogramme
Wenn da nur 255 Zeichen als Stringlänge vorgesehen sind, muss das Programm
zwangsläufig crashen wenn es auf einen längeren String zugreifen soll.
>
>Nach meinem Kenntnisstand gibt es keine vom Betriebssystem festgelegte
>Obergrenze.
Standardmäßig sind die langen Pfade deaktiviert
>Nach meinem Kenntnisstand gibt es keine vom Betriebssystem festgelegte
>Obergrenze.
Muss man sie erst mit gpedit explizit freischalten, wie auch in dem Artikel
beschrieben.
(Oder die Registry manuell ändern)
Bleibt die Frage:
Wie lang darf der Pfad max. sein?
Gruß
Jürgen
Heiko Rost
Dec 10, 2016, 5:55:47 PM12/10/16
to
Jürgen Meyer schrieb:
> Auf
> https://www.deskmodder.de/blog/2016/05/28/windows-10-laengenbegrenzung-von-260-zeichen-kann-nun-aufgehoben-werden/
> gibt es den obigen Beitrag.
> Ich bin mir der Problematik mit überlangen Pfaden bewusst
> Das ist also nicht die Frage
Windows kann intern schon seit einiger Zeit mit Pfadnamen länger als
MAXPATH umgehen, wenn man man UNC-Namen benutzt. Das Problem sind die
Programme (zu denen mindestens bis Windows 7 auch der Explorer gehört),
die das nicht können.
> Meine Frage ist aber:
> Wie lang darf der Pfad denn nun werden?
32,767 Zeichen.
> Dazu konnte ich bisher nichts finden
<https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247>
dürfte eine gute Quelle zu dem Thema sein.
Gruß Heiko
--
Der Mensch ist gut, nur die Nerven sind schlecht.
Mose Ya'aqob Ben-Gavriêl
> Auf
> https://www.deskmodder.de/blog/2016/05/28/windows-10-laengenbegrenzung-von-260-zeichen-kann-nun-aufgehoben-werden/
> gibt es den obigen Beitrag.
> Ich bin mir der Problematik mit überlangen Pfaden bewusst
> Das ist also nicht die Frage
MAXPATH umgehen, wenn man man UNC-Namen benutzt. Das Problem sind die
Programme (zu denen mindestens bis Windows 7 auch der Explorer gehört),
die das nicht können.
> Meine Frage ist aber:
> Wie lang darf der Pfad denn nun werden?
> Dazu konnte ich bisher nichts finden
dürfte eine gute Quelle zu dem Thema sein.
Gruß Heiko
--
Der Mensch ist gut, nur die Nerven sind schlecht.
Mose Ya'aqob Ben-Gavriêl
Stefan Kanthak
Dec 10, 2016, 5:56:55 PM12/10/16
to
"Jürgen Meyer" <juergen....@gmx.de> schrieb:
>>> Ich bin mir der Problematik mit überlangen Pfaden bewusst
TRAEUM WEITER, Ahnungsloser!
>>Wobei es mich wundert, dass das unter Windows 10 immer noch ein Problem
>>ist. Eigentlich dachte ich, dass das schon längst behoben wäre.
>
> Nicht Windows 10 ist das Problem.
> Es sind die Anwenderprogramme
> Wenn da nur 255 Zeichen als Stringlänge vorgesehen sind,
dann ist der Verbrecher dieses kaputten Programms genauso ahnungslos wie
Du: MAX_PATH existiert NOCH laenger als eNTe und ist groesser als 255!
> muss das Programm zwangsläufig crashen wenn es auf einen längeren String
> zugreifen soll.
Wieder falsch, und selbstverstaendlich VOELLIGER Bloedsinn: die
Pfadnamen liefernden Funktionen des Win32-API werden alle mit der
Laenge des Puffers gefuettert und liefern die ggf. benoetigte Laenge
zurueck.
>>> Ich bin mir der Problematik mit überlangen Pfaden bewusst
>>Wobei es mich wundert, dass das unter Windows 10 immer noch ein Problem
>>ist. Eigentlich dachte ich, dass das schon längst behoben wäre.
>
> Nicht Windows 10 ist das Problem.
> Es sind die Anwenderprogramme
> Wenn da nur 255 Zeichen als Stringlänge vorgesehen sind,
Du: MAX_PATH existiert NOCH laenger als eNTe und ist groesser als 255!
> muss das Programm zwangsläufig crashen wenn es auf einen längeren String
> zugreifen soll.
Pfadnamen liefernden Funktionen des Win32-API werden alle mit der
Laenge des Puffers gefuettert und liefern die ggf. benoetigte Laenge
zurueck.
Christoph Schneegans
Dec 10, 2016, 6:17:17 PM12/10/16
to
Stefan Kanthak schrieb:
> <https://msdn.microsoft.com/en-us/library/aa365247.aspx>
Ich habe den dort (im Fragment #maxpath) erwähnten Registry-Wert
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001
gesetzt, bemerke aber auch nach Neustart des Computers keine Änderungen.
Windows Shell, PowerShell und auch ein .NET-Programm bringen weiterhin
eine Fehlermeldung, wenn man versucht, eine Datei mit einem 1000 Zeichen
langen Namen anzulegen: "The specified path, file name, or both are too
long. The fully qualified file name must be less than 260 characters, and
the directory name must be less than 248 characters."
Was wären denn konkret die Änderungen, die man mit dem o.g. Registry-Wert
erwarten darf?
--
<http://schneegans.de/computer/safer/> · SAFER mit Windows
> <https://msdn.microsoft.com/en-us/library/aa365247.aspx>
Ich habe den dort (im Fragment #maxpath) erwähnten Registry-Wert
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001
gesetzt, bemerke aber auch nach Neustart des Computers keine Änderungen.
Windows Shell, PowerShell und auch ein .NET-Programm bringen weiterhin
eine Fehlermeldung, wenn man versucht, eine Datei mit einem 1000 Zeichen
langen Namen anzulegen: "The specified path, file name, or both are too
long. The fully qualified file name must be less than 260 characters, and
the directory name must be less than 248 characters."
Was wären denn konkret die Änderungen, die man mit dem o.g. Registry-Wert
erwarten darf?
--
<http://schneegans.de/computer/safer/> · SAFER mit Windows
Stefan Kanthak
Dec 10, 2016, 7:46:27 PM12/10/16
to
"Christoph Schneegans" <Chri...@Schneegans.de> schrieb:
> Stefan Kanthak schrieb:
>
>> <https://msdn.microsoft.com/en-us/library/aa365247.aspx>
>
> Ich habe den dort (im Fragment #maxpath) erwähnten Registry-Wert
>
> Windows Registry Editor Version 5.00
>
> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
> "LongPathsEnabled"=dword:00000001
>
> gesetzt, bemerke aber auch nach Neustart des Computers keine Änderungen.
> Windows Shell,
Neustart ist nicht noetig, diese Einstellung wirkt fuer alle danach
gestarteten Prozesse; sie wird beim ersten Aufruf einer auf das
Dateisystem zugreifenden Schnittstelle des Win32-API ausgewertet.
JFTR: beim File Explorer erwarte ich davon KEINE Aenderung: ich argwoehne,
dass der auch weiterhin auf MAX_PATH beschraenkt ist.
> PowerShell und auch ein .NET-Programm bringen weiterhin
> eine Fehlermeldung, wenn man versucht, eine Datei mit einem 1000 Zeichen
Die Einstellung lautet "*Paths*", nicht "*Files*" ...
Die Maximallaenge der einzelnen (durch \ getrennten) Elemente von Pfadnamen
ist unveraendert 255 Zeichen.
> langen Namen anzulegen: "The specified path, file name, or both are too
> long. The fully qualified file name must be less than 260 characters, and
> the directory name must be less than 248 characters."
>
> Was wären denn konkret die Änderungen, die man mit dem o.g. Registry-Wert
> erwarten darf?
Dass diese Programme/Anwendungen PFAD-Namen mit mehr als 259 Zeichen
verarbeiten koennen.
> Stefan Kanthak schrieb:
>
>> <https://msdn.microsoft.com/en-us/library/aa365247.aspx>
>
> Ich habe den dort (im Fragment #maxpath) erwähnten Registry-Wert
>
> Windows Registry Editor Version 5.00
>
> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
> "LongPathsEnabled"=dword:00000001
>
> gesetzt, bemerke aber auch nach Neustart des Computers keine Änderungen.
> Windows Shell,
gestarteten Prozesse; sie wird beim ersten Aufruf einer auf das
Dateisystem zugreifenden Schnittstelle des Win32-API ausgewertet.
JFTR: beim File Explorer erwarte ich davon KEINE Aenderung: ich argwoehne,
dass der auch weiterhin auf MAX_PATH beschraenkt ist.
> PowerShell und auch ein .NET-Programm bringen weiterhin
> eine Fehlermeldung, wenn man versucht, eine Datei mit einem 1000 Zeichen
Die Maximallaenge der einzelnen (durch \ getrennten) Elemente von Pfadnamen
ist unveraendert 255 Zeichen.
> langen Namen anzulegen: "The specified path, file name, or both are too
> long. The fully qualified file name must be less than 260 characters, and
> the directory name must be less than 248 characters."
>
> Was wären denn konkret die Änderungen, die man mit dem o.g. Registry-Wert
> erwarten darf?
verarbeiten koennen.
Arno Welzel
Dec 10, 2016, 8:19:12 PM12/10/16
to
Claus Reibenstein wrote:
> Jürgen Meyer schrieb am 10.12.2016 um 22:30:
>
>> Auf
>> https://www.deskmodder.de/blog/2016/05/28/windows-10-laengenbegrenzung-von-260-zeichen-kann-nun-aufgehoben-werden/
>> gibt es den obigen Beitrag.
>
> Der bereits über ein halbes Jahr alt ist.
>
>> Ich bin mir der Problematik mit überlangen Pfaden bewusst
>
> Wobei es mich wundert, dass das unter Windows 10 immer noch ein Problem
> ist. Eigentlich dachte ich, dass das schon längst behoben wäre.
Das Problem ist weniger Windows, als die ganzen Anwendungen, die ja auch
> Jürgen Meyer schrieb am 10.12.2016 um 22:30:
>
>> Auf
>> https://www.deskmodder.de/blog/2016/05/28/windows-10-laengenbegrenzung-von-260-zeichen-kann-nun-aufgehoben-werden/
>> gibt es den obigen Beitrag.
>
> Der bereits über ein halbes Jahr alt ist.
>
>> Ich bin mir der Problematik mit überlangen Pfaden bewusst
>
> Wobei es mich wundert, dass das unter Windows 10 immer noch ein Problem
> ist. Eigentlich dachte ich, dass das schon längst behoben wäre.
Pfade an diversen Stellen verarbeiten müssen - etwa um den Namen einer
Datei in einer Variable zu speichern.
[...]
> Es ist schon merkwürdig und manchmal auch ziemlich ärgerlich, mit was
> für unsinnigen Kleinigkeiten man sich unter Windows auseinandersetzen
> muss. Von Linux & Co kenne ich dieses Problem nicht.
Auch bei Linux gibt es keine unbegrenzte Pfadlänge, die Grenzen sind nur
> für unsinnigen Kleinigkeiten man sich unter Windows auseinandersetzen
> muss. Von Linux & Co kenne ich dieses Problem nicht.
höher:
<http://ask.systutorials.com/1504/maximum-allowed-file-path-length-for-c-programming-on-linux>
--
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de
Christoph Schneegans
Dec 10, 2016, 8:59:42 PM12/10/16
to
Stefan Kanthak schrieb:
>>> <https://msdn.microsoft.com/en-us/library/aa365247.aspx>
>>
>> Ich habe den dort (im Fragment #maxpath) erwähnten Registry-Wert
>>
>> Windows Registry Editor Version 5.00
>>
>> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
>> "LongPathsEnabled"=dword:00000001
>>
>> gesetzt, bemerke aber auch nach Neustart des Computers keine Änderungen.
>
>>> <https://msdn.microsoft.com/en-us/library/aa365247.aspx>
>>
>> Ich habe den dort (im Fragment #maxpath) erwähnten Registry-Wert
>>
>> Windows Registry Editor Version 5.00
>>
>> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
>> "LongPathsEnabled"=dword:00000001
>>
>> gesetzt, bemerke aber auch nach Neustart des Computers keine Änderungen.
>
> Die Einstellung lautet "*Paths*", nicht "*Files*" ...
> Die Maximallaenge der einzelnen (durch \ getrennten) Elemente von Pfadnamen
> ist unveraendert 255 Zeichen.
Okay, verstanden. Die Ergebnisse sind dennoch durchwachsen. Mit PowerShell
> Die Maximallaenge der einzelnen (durch \ getrennten) Elemente von Pfadnamen
> ist unveraendert 255 Zeichen.
kann ich etwa per
mkdir ("C:\Users\chris\Desktop\" + "fooooooooooooooooooooooooooooooooooooooooooooooooo\" * 500)
ein Verzeichnis
C:\Users\chris\Desktop\fooooooooooooooooooooooooooooooooooooooooooooooooo\…\fooooooooooooooooooooooooooooooooooooooooooooooooo
erstellen, und
dir -path C:\Users\chris\Desktop\ -Recurse -Directory | select -Last 1 | select {$_.FullName.Length}
zeigt dann auch eine imposante Pfadlänge an:
$_.FullName.Length
------------------
25522
Der Windows-Explorer jedoch liefert folgende Fehlermeldung, wenn ich
versuche, das oberste Verzeichnis zu löschen:
"The source file name(s) are larger than is supported by the file system."
Das ist ja wohl glatt gelogen. Und in cmd.exe bricht
dir /s
auch nach wenigen Unterverzeichnissen ab:
The directory name C:\Users\chris\Desktop\…\fooooooooooooooooooooooooooooooooooooooooooooooooo is too long.
Der monierte Pfad hat eine Länge von nur 277 Zeichen.
Thorsten Albrecht
Dec 11, 2016, 11:44:14 AM12/11/16
to
Heiko Rost <heiko...@gmx.de> wrote:
>Windows kann intern schon seit einiger Zeit mit Pfadnamen länger als
>MAXPATH umgehen, wenn man man UNC-Namen benutzt.
Kleine Korrektur:
>Windows kann intern schon seit einiger Zeit mit Pfadnamen länger als
>MAXPATH umgehen, wenn man man UNC-Namen benutzt.
Windows kann intern schon seit einiger Zeit mit Pfadnamen länger als
...umgehen, wenn man dem Laufwerksbuchstaben ein "\\?" voranstellt:
"\\?\D:\very long path"
Dieser Präfix kann auch bei UNC-Pfaden verwendet werden:
"\\?\UNC\server\share\long_path"
Ich benutze \\? im Alltag eigentlich nur bei meinem
Synchronisationstool Vice Versa Pro.
Thorsten
Claus Reibenstein
Dec 11, 2016, 2:51:41 PM12/11/16
to
Thorsten Albrecht schrieb am 11.12.2016 um 17:44:
> Windows kann intern schon seit einiger Zeit mit Pfadnamen länger als
> MAXPATH ...
> ....umgehen, wenn man dem Laufwerksbuchstaben ein "\\?" voranstellt:
> Windows kann intern schon seit einiger Zeit mit Pfadnamen länger als
> MAXPATH ...
Mal abgesehen von der fraglichen Sinnhaftigkeit solcher Krücken: Wo und
wie findet man solche Informationen?
Gruß
Claus
Heiko Rost
Dec 11, 2016, 3:38:51 PM12/11/16
to
Claus Reibenstein schrieb:
> Mal abgesehen von der fraglichen Sinnhaftigkeit solcher Krücken: Wo
Im bereits genannten Link bei Microsoft.
<https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247>
| The Windows API has many functions that also have Unicode versions to
| permit an extended-length path for a maximum total path length of
| 32,767 characters. This type of path is composed of components
| separated by backslashes, each up to the value returned in the
| lpMaximumComponentLength parameter of the GetVolumeInformation
| function (this value is commonly 255 characters). To specify an
| extended-length path, use the "\\?\" prefix. For example,
| "\\?\D:\very long path".
> und wie findet man solche Informationen?
Unter XP hatte ich ein Programm, das öfters Dateien mit solchen
überlangen Namen angelegt hat. Nachdem diese sich im Explorer
erfolgreich jeder Aktion entzogen haben, hatte ich mich dann auf die
Suche gemacht, wie diese Namen erzeugt und ggf. auch umbenannt/gelöscht
werden können.
Gruß Heiko
--
So mancher meint, ein gutes Herz zu haben, und hat nur schwache Nerven.
Marie Freifrau von Ebner-Eschenbach
> Mal abgesehen von der fraglichen Sinnhaftigkeit solcher Krücken: Wo
<https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247>
| The Windows API has many functions that also have Unicode versions to
| permit an extended-length path for a maximum total path length of
| 32,767 characters. This type of path is composed of components
| separated by backslashes, each up to the value returned in the
| lpMaximumComponentLength parameter of the GetVolumeInformation
| function (this value is commonly 255 characters). To specify an
| extended-length path, use the "\\?\" prefix. For example,
| "\\?\D:\very long path".
> und wie findet man solche Informationen?
überlangen Namen angelegt hat. Nachdem diese sich im Explorer
erfolgreich jeder Aktion entzogen haben, hatte ich mich dann auf die
Suche gemacht, wie diese Namen erzeugt und ggf. auch umbenannt/gelöscht
werden können.
Gruß Heiko
--
So mancher meint, ein gutes Herz zu haben, und hat nur schwache Nerven.
Marie Freifrau von Ebner-Eschenbach
Heiko Rost
Dec 11, 2016, 3:44:07 PM12/11/16
to
Thorsten Albrecht schrieb:
> Heiko Rost <heiko...@gmx.de> wrote:
>
>>Windows kann intern schon seit einiger Zeit mit Pfadnamen länger als
>>MAXPATH umgehen, wenn man man UNC-Namen benutzt.
>
> Kleine Korrektur:
>
> Windows kann intern schon seit einiger Zeit mit Pfadnamen länger als
> MAXPATH ...
> ...umgehen, wenn man dem Laufwerksbuchstaben ein "\\?" voranstellt:
>
> "\\?\D:\very long path"
Den Trick meinte ich, dabei hatte ich falsch in Erinnerung, daß das mit
zu den Universal Naming Conventions gehört.
Gruß Heiko
--
Die Seele ist eine treulose Tomate. Wenn es ihr gut tut, belügt sie auch
sich selbst.
Tom Borg
> Heiko Rost <heiko...@gmx.de> wrote:
>
>>Windows kann intern schon seit einiger Zeit mit Pfadnamen länger als
>>MAXPATH umgehen, wenn man man UNC-Namen benutzt.
>
> Kleine Korrektur:
>
> Windows kann intern schon seit einiger Zeit mit Pfadnamen länger als
> MAXPATH ...
> ...umgehen, wenn man dem Laufwerksbuchstaben ein "\\?" voranstellt:
>
> "\\?\D:\very long path"
zu den Universal Naming Conventions gehört.
Gruß Heiko
--
Die Seele ist eine treulose Tomate. Wenn es ihr gut tut, belügt sie auch
sich selbst.
Tom Borg
Stefan Kanthak
Dec 11, 2016, 4:36:20 PM12/11/16
to
"Falk Duebbert" <fa...@duebbert.com> schrieb:
Wie ueblich: VOELLIG ahnungslos!
> Christoph Schneegans:
>> Und in cmd.exe bricht
>
> Im Grunde ist das nicht gelogen.
Selbstverstaendlich ist das eine dummdreiste Luege: NTFS unterstuetzt
seit Anbeginn der Zeiten 32767 Zeichen lange Pfadnamen, und 255 Zeichen
lange Datei- sowie Verzeichnisnnamen.
> Die Powershell nutzt ggf. die aktualisierte System.IO API
S.o.: VOELLIG ahnungslos.
Es gibt keine "aktualisierten" Win32-Schnittstellen: deren Unicode-
Varianten unterstuetzen als EINGABE-Parameter Pfade mit mehr als
MAX_PATH Zeichen schon seit ueber 20 Jahren.
Bisher brauchten sie dafuer allerdings das Praefix "\\?\".
Als AUSGABE-Parameter werden lange Pfade voellig unabhaengig davon
schon IMMER unterstuetzt.
> und der Explorer oder die cmd die legacy-Variante.
Die gibt es nicht.
> Mir wären Pafdnamen über 200 Zeichen zu "heiß";
Dann solltest Du Dich von NTFS oder aktuellen Betruebssystemen fernhalten!
> wobei ich auch mit 8.3 und einer 5,25" pro Benutzer aufgewachsen bin.
Es soll Leute geben, die sich durch CP/M oder PC-DOS nicht versauen
liessen!
JFTR: schon NT 4.0 lief OHNE diese verstuemmelten 8.3-Dateinamen VOELLIG
problemlos!
Wie ueblich: VOELLIG ahnungslos!
> Christoph Schneegans:
>>
>> Der Windows-Explorer jedoch liefert folgende Fehlermeldung, wenn ich
>> versuche, das oberste Verzeichnis zu löschen:
>>
>> "The source file name(s) are larger than is supported by the file system."
>>
>> Das ist ja wohl glatt gelogen.
Richtig.
>> Der Windows-Explorer jedoch liefert folgende Fehlermeldung, wenn ich
>> versuche, das oberste Verzeichnis zu löschen:
>>
>> "The source file name(s) are larger than is supported by the file system."
>>
>> Das ist ja wohl glatt gelogen.
>> Und in cmd.exe bricht
>
> Im Grunde ist das nicht gelogen.
Selbstverstaendlich ist das eine dummdreiste Luege: NTFS unterstuetzt
seit Anbeginn der Zeiten 32767 Zeichen lange Pfadnamen, und 255 Zeichen
lange Datei- sowie Verzeichnisnnamen.
> Die Powershell nutzt ggf. die aktualisierte System.IO API
S.o.: VOELLIG ahnungslos.
Es gibt keine "aktualisierten" Win32-Schnittstellen: deren Unicode-
Varianten unterstuetzen als EINGABE-Parameter Pfade mit mehr als
MAX_PATH Zeichen schon seit ueber 20 Jahren.
Bisher brauchten sie dafuer allerdings das Praefix "\\?\".
Als AUSGABE-Parameter werden lange Pfade voellig unabhaengig davon
schon IMMER unterstuetzt.
> und der Explorer oder die cmd die legacy-Variante.
Die gibt es nicht.
> Mir wären Pafdnamen über 200 Zeichen zu "heiß";
Dann solltest Du Dich von NTFS oder aktuellen Betruebssystemen fernhalten!
> wobei ich auch mit 8.3 und einer 5,25" pro Benutzer aufgewachsen bin.
Es soll Leute geben, die sich durch CP/M oder PC-DOS nicht versauen
liessen!
JFTR: schon NT 4.0 lief OHNE diese verstuemmelten 8.3-Dateinamen VOELLIG
problemlos!
Stefan Kanthak
Dec 11, 2016, 5:17:22 PM12/11/16
to
"Christoph Schneegans" <Chri...@Schneegans.de> schrieb:
[...]
>> Die Maximallaenge der einzelnen (durch \ getrennten) Elemente von Pfadnamen
>> ist unveraendert 255 Zeichen.
>
> Okay, verstanden. Die Ergebnisse sind dennoch durchwachsen. Mit PowerShell
> kann ich etwa per
>
> mkdir ("C:\Users\chris\Desktop\" + "fooooooooooooooooooooooooooooooooooooooooooooooooo\" * 500)
>
> ein Verzeichnis
>
> C:\Users\chris\Desktop\fooooooooooooooooooooooooooooooooooooooooooooooooo\…\fooooooooooooooooooooooooooooooooooooooooooooooooo
>
> erstellen, und
>
> dir -path C:\Users\chris\Desktop\ -Recurse -Directory | select -Last 1 | select {$_.FullName.Length}
>
> zeigt dann auch eine imposante Pfadlänge an:
>
> $_.FullName.Length
> ------------------
> 25522
.NET und damit auch PowerShell wurden dafuer fit gemacht, indem die
Beschraenkung von EINGABE-Parametern in deren Pfadnamen bearbeitenden
Routinen auf MAX_PATH beseitigt wurde.
<https://blogs.msdn.microsoft.com/jeremykuhne/2016/06/09/new-net-path-handling-sneak-peek/>
<https://blogs.msdn.microsoft.com/jeremykuhne/2016/06/21/more-on-new-net-path-handling/>
<https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/>
Bei AUSGABE-Parametern waren laengere Pfade schon immer moeglich, da
das Win32-API diese seit ueber 20 Jahren liefert, und zu kurze Puffer
natuerlich per Returncode meldet.
> Der Windows-Explorer jedoch liefert folgende Fehlermeldung, wenn ich
> versuche, das oberste Verzeichnis zu löschen:
>
> "The source file name(s) are larger than is supported by the file system."
>
> Das ist ja wohl glatt gelogen.
Korrekt: eine dummdreiste Luege, weil die Verbrecher der "shell" das
System, auf dem ihr Verbrechen laeuft, offensichtlich NICHT kennen!
> Und in cmd.exe bricht
>
> dir /s
>
> auch nach wenigen Unterverzeichnissen ab:
>
> The directory name C:\Users\chris\Desktop\…\fooooooooooooooooooooooooooooooooooooooooooooooooo is too long.
>
> Der monierte Pfad hat eine Länge von nur 277 Zeichen.
"too long" fuer den Kommandointerpreter: auch dessen Verbrecher kennen
nur MAX_PATH
Stefan
PS: kopiere mal NOTEPAD.EXE nach %windir%\TEMP und gib dann in der
Eingabeaufforderung oder bei Start->Ausfuehren TEMP\NOTEPAD.EXE ein.
Nachdem Du die dummdreiste Luege "kann TEMP\NOTEPAD.EXE nicht finden"
beider Programme gesehen hast rufst Du die Funktion CreateProcess()
(siehe https://msdn.microsoft.com/en-us/library/ms682425.aspx)
des Win32-API wie folgt auf:
STARTUPINFO si = {sizeof(STARTUPINFO)};
PROCESS_INFORMATION pi = {0};
CreateProcess(NULL, "TEMP\\NOTEPAD.EXE", NULL, NULL, FALSE, 0L, NULL, NULL, &si, &pi);
und wunderst Dich hoffentlich nicht, dass Windows auch relative
Pfadnamen korrekt verarbeitet.
LoadLibrary("TEMP\\NOTEPAD.EXE") funktioniert selbstverstaendlich
auch ... wie in
<https://msdn.microsoft.com/en-us/library/ms684175.aspx> EXPLIZIT
beschrieben:
| If a relative path is specified, the entire relative path is
| appended to every token in the DLL search path list.
Bei CreateProcess() fehlt dieser explizite Hinweise dummerweise...
[...]
>> Die Maximallaenge der einzelnen (durch \ getrennten) Elemente von Pfadnamen
>> ist unveraendert 255 Zeichen.
>
> Okay, verstanden. Die Ergebnisse sind dennoch durchwachsen. Mit PowerShell
> kann ich etwa per
>
> mkdir ("C:\Users\chris\Desktop\" + "fooooooooooooooooooooooooooooooooooooooooooooooooo\" * 500)
>
> ein Verzeichnis
>
> C:\Users\chris\Desktop\fooooooooooooooooooooooooooooooooooooooooooooooooo\…\fooooooooooooooooooooooooooooooooooooooooooooooooo
>
> erstellen, und
>
> dir -path C:\Users\chris\Desktop\ -Recurse -Directory | select -Last 1 | select {$_.FullName.Length}
>
> zeigt dann auch eine imposante Pfadlänge an:
>
> $_.FullName.Length
> ------------------
> 25522
Beschraenkung von EINGABE-Parametern in deren Pfadnamen bearbeitenden
Routinen auf MAX_PATH beseitigt wurde.
<https://blogs.msdn.microsoft.com/jeremykuhne/2016/06/09/new-net-path-handling-sneak-peek/>
<https://blogs.msdn.microsoft.com/jeremykuhne/2016/06/21/more-on-new-net-path-handling/>
<https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/>
Bei AUSGABE-Parametern waren laengere Pfade schon immer moeglich, da
das Win32-API diese seit ueber 20 Jahren liefert, und zu kurze Puffer
natuerlich per Returncode meldet.
> Der Windows-Explorer jedoch liefert folgende Fehlermeldung, wenn ich
> versuche, das oberste Verzeichnis zu löschen:
>
> "The source file name(s) are larger than is supported by the file system."
>
> Das ist ja wohl glatt gelogen.
System, auf dem ihr Verbrechen laeuft, offensichtlich NICHT kennen!
> Und in cmd.exe bricht
>
> dir /s
>
> auch nach wenigen Unterverzeichnissen ab:
>
> The directory name C:\Users\chris\Desktop\…\fooooooooooooooooooooooooooooooooooooooooooooooooo is too long.
>
> Der monierte Pfad hat eine Länge von nur 277 Zeichen.
nur MAX_PATH
Stefan
PS: kopiere mal NOTEPAD.EXE nach %windir%\TEMP und gib dann in der
Eingabeaufforderung oder bei Start->Ausfuehren TEMP\NOTEPAD.EXE ein.
Nachdem Du die dummdreiste Luege "kann TEMP\NOTEPAD.EXE nicht finden"
beider Programme gesehen hast rufst Du die Funktion CreateProcess()
(siehe https://msdn.microsoft.com/en-us/library/ms682425.aspx)
des Win32-API wie folgt auf:
STARTUPINFO si = {sizeof(STARTUPINFO)};
PROCESS_INFORMATION pi = {0};
CreateProcess(NULL, "TEMP\\NOTEPAD.EXE", NULL, NULL, FALSE, 0L, NULL, NULL, &si, &pi);
und wunderst Dich hoffentlich nicht, dass Windows auch relative
Pfadnamen korrekt verarbeitet.
LoadLibrary("TEMP\\NOTEPAD.EXE") funktioniert selbstverstaendlich
auch ... wie in
<https://msdn.microsoft.com/en-us/library/ms684175.aspx> EXPLIZIT
beschrieben:
| If a relative path is specified, the entire relative path is
| appended to every token in the DLL search path list.
Bei CreateProcess() fehlt dieser explizite Hinweise dummerweise...
Ingo Steinbuechel
Dec 12, 2016, 3:57:18 AM12/12/16
to
Hallo Claus,
"Claus Reibenstein" <4spame...@kabelmail.de> schrieb:
> Wo und wie findet man solche Informationen?
http://de.lmgtfy.com/?q=win+max+path
Bei mir der erste Ergebnislink. Bei Dir nicht?
Gruß Ingo
"Claus Reibenstein" <4spame...@kabelmail.de> schrieb:
> Wo und wie findet man solche Informationen?
Bei mir der erste Ergebnislink. Bei Dir nicht?
Gruß Ingo
Claus Reibenstein
Dec 12, 2016, 4:07:40 AM12/12/16
to
Ingo Steinbuechel schrieb am 12.12.2016 um 09:56:
> Hallo Claus,
>
> "Claus Reibenstein" <4spame...@kabelmail.de> schrieb:
Bitte nur eine Einleitungszeile. Und lass die Mailadresse weg. Die ist
> Hallo Claus,
>
> "Claus Reibenstein" <4spame...@kabelmail.de> schrieb:
eh' nur für Spammer.
Meine Frage war nicht, wie man _diese_ Information findet, sondern
_solche_ Informationen. Das ist ein kleiner Unterschied.
Natürlich kenne ich Google & Co und kann damit auch umgehen, und wenn
ich gezielt nach etwas suche, finde ich es i.d.R. auch. Wenn ich aber
wissen möchte, welche versteckten Möglichkeiten Windows sonst noch
bietet, hilft mir Google in keinster Weise.
Gruß
Claus
Takvorian
Dec 12, 2016, 6:54:16 AM12/12/16
to
Claus Reibenstein schrieb:
> Wenn ich aber
> wissen möchte, welche versteckten Möglichkeiten Windows sonst noch
> bietet, hilft mir Google in keinster Weise.
Entsprechende Suchkompetenz vorausgesetzt, findet man alles.
Dummerweise hilft einem das nichts, sofern das Fachwissen zur korrekten
Einordnung der Ergebnisse fehlt.
> Wenn ich aber
> wissen möchte, welche versteckten Möglichkeiten Windows sonst noch
> bietet, hilft mir Google in keinster Weise.
Dummerweise hilft einem das nichts, sofern das Fachwissen zur korrekten
Einordnung der Ergebnisse fehlt.
Takvorian
Dec 12, 2016, 7:04:52 AM12/12/16
to
Stefan Kanthak schrieb:
> "Christoph Schneegans" <Chri...@Schneegans.de> schrieb:
>> Der monierte Pfad hat eine Länge von nur 277 Zeichen.
> "too long" fuer den Kommandointerpreter: auch dessen Verbrecher kennen
> nur MAX_PATH
Nett auch das Theater in Win 10-1511, wenn die Suche in der Registrierung
auf einen Schlüssel stieß, dessen kompletter Pfad länger als 255 Zeichen
war.
> "Christoph Schneegans" <Chri...@Schneegans.de> schrieb:
>> Der monierte Pfad hat eine Länge von nur 277 Zeichen.
> "too long" fuer den Kommandointerpreter: auch dessen Verbrecher kennen
> nur MAX_PATH
auf einen Schlüssel stieß, dessen kompletter Pfad länger als 255 Zeichen
war.
Stefan Kanthak
Dec 12, 2016, 2:30:25 PM12/12/16
to
"Claus Reibenstein" <4spame...@kabelmail.de> schrieb:
> Ingo Steinbuechel schrieb am 12.12.2016 um 09:56:
[...]
>>> Wo und wie findet man solche Informationen?
>>
>> http://de.lmgtfy.com/?q=win+max+path
>
> Meine Frage war nicht, wie man _diese_ Information findet, sondern
> _solche_ Informationen. Das ist ein kleiner Unterschied.
>
> Natürlich kenne ich Google & Co und kann damit auch umgehen, und wenn
> ich gezielt nach etwas suche, finde ich es i.d.R. auch. Wenn ich aber
> wissen möchte, welche versteckten Möglichkeiten Windows sonst noch
> bietet, hilft mir Google in keinster Weise.
Du, Du musst jetzt GAAANZ stark sein: solche, fuer Dich unerreichbar
versteckten Informationen kann jeder nicht VOELLIG Unfaehige OHNE Google
oder eine andere Suchmaschine seit VIELEN Jahren ganz offen in den zig
MSDN-Seiten finden und lesen, die Pfadnamen entgegennehmende Win32-
Schnittstellen wie
* CreateFile()
<https://msdn.microsoft.com/en-us/library/aa363858.aspx>
* CreateDirectory()
<https://msdn.microsoft.com/en-us/library/aa363855.aspx>
* CreateHardLink()
<https://msdn.microsoft.com/en-us/library/aa363860.aspx>
* CopyFile()
<https://msdn.microsoft.com/en-us/library/aa363851.aspx>
* GetLongPathName()
<https://msdn.microsoft.com/en-us/library/aa364980.aspx>
* GetShortPathName()
<https://msdn.microsoft.com/en-us/library/aa364989.aspx>
* SetCurrentDirectory()
<https://msdn.microsoft.com/en-us/library/aa365530.aspx>
und VIELE weitere beschreiben, oder gar in Artikeln wie
"Creating, Deleting, and Maintaining Files"
<https://msdn.microsoft.com/en-us/library/aa363879.aspx>
wehret den UNFAEHIGEN!
Stefan
> Ingo Steinbuechel schrieb am 12.12.2016 um 09:56:
>>> Wo und wie findet man solche Informationen?
>>
>> http://de.lmgtfy.com/?q=win+max+path
>
> Meine Frage war nicht, wie man _diese_ Information findet, sondern
> _solche_ Informationen. Das ist ein kleiner Unterschied.
>
> Natürlich kenne ich Google & Co und kann damit auch umgehen, und wenn
> ich gezielt nach etwas suche, finde ich es i.d.R. auch. Wenn ich aber
> wissen möchte, welche versteckten Möglichkeiten Windows sonst noch
> bietet, hilft mir Google in keinster Weise.
versteckten Informationen kann jeder nicht VOELLIG Unfaehige OHNE Google
oder eine andere Suchmaschine seit VIELEN Jahren ganz offen in den zig
MSDN-Seiten finden und lesen, die Pfadnamen entgegennehmende Win32-
Schnittstellen wie
* CreateFile()
<https://msdn.microsoft.com/en-us/library/aa363858.aspx>
* CreateDirectory()
<https://msdn.microsoft.com/en-us/library/aa363855.aspx>
* CreateHardLink()
<https://msdn.microsoft.com/en-us/library/aa363860.aspx>
* CopyFile()
<https://msdn.microsoft.com/en-us/library/aa363851.aspx>
* GetLongPathName()
<https://msdn.microsoft.com/en-us/library/aa364980.aspx>
* GetShortPathName()
<https://msdn.microsoft.com/en-us/library/aa364989.aspx>
* SetCurrentDirectory()
<https://msdn.microsoft.com/en-us/library/aa365530.aspx>
und VIELE weitere beschreiben, oder gar in Artikeln wie
"Creating, Deleting, and Maintaining Files"
<https://msdn.microsoft.com/en-us/library/aa363879.aspx>
wehret den UNFAEHIGEN!
Stefan
Detlef Meißner
Dec 12, 2016, 2:37:13 PM12/12/16
to
Am 12.12.2016 um 20:17 schrieb Stefan Kanthak:
> "Claus Reibenstein" <4spame...@kabelmail.de> schrieb:
>> Natürlich kenne ich Google & Co und kann damit auch umgehen, und wenn
>> ich gezielt nach etwas suche, finde ich es i.d.R. auch. Wenn ich aber
>> wissen möchte, welche versteckten Möglichkeiten Windows sonst noch
>> bietet, hilft mir Google in keinster Weise.
>
> Du, Du musst jetzt GAAANZ stark sein: solche, fuer Dich unerreichbar
> versteckten Informationen kann jeder nicht VOELLIG Unfaehige OHNE Google
> oder eine andere Suchmaschine seit VIELEN Jahren ganz offen in den zig
> MSDN-Seiten finden und lesen, die Pfadnamen entgegennehmende Win32-
> Schnittstellen wie
[Snipp]
>
> wehret den UNFAEHIGEN!
Ja, ein Leben ist unerträglich. Umgeben nur von Unfähigen.
Detlef
> "Claus Reibenstein" <4spame...@kabelmail.de> schrieb:
>> Natürlich kenne ich Google & Co und kann damit auch umgehen, und wenn
>> ich gezielt nach etwas suche, finde ich es i.d.R. auch. Wenn ich aber
>> wissen möchte, welche versteckten Möglichkeiten Windows sonst noch
>> bietet, hilft mir Google in keinster Weise.
>
> Du, Du musst jetzt GAAANZ stark sein: solche, fuer Dich unerreichbar
> versteckten Informationen kann jeder nicht VOELLIG Unfaehige OHNE Google
> oder eine andere Suchmaschine seit VIELEN Jahren ganz offen in den zig
> MSDN-Seiten finden und lesen, die Pfadnamen entgegennehmende Win32-
> Schnittstellen wie
>
> wehret den UNFAEHIGEN!
Ja, ein Leben ist unerträglich. Umgeben nur von Unfähigen.
Detlef
Thorsten Albrecht
Dec 12, 2016, 3:42:14 PM12/12/16
to
welches ich zur Synchronisation einsetze:
http://www.tgrmn.com/web/kb/item31.htm
So lange man keine Probleme beim Einsatz _ohne_ "\\?" hat, benötigt
man diese Information auch nicht. Und wenn man die Probleme bekommt,
kommt man doch relativ leicht auf den Begriff "maximale Pfadlänge in
Windows" und damit auch zur \\?-Notation.
Korrektur: Beim allerersten Kontakt mit \\? hatte ich das Problem,
einen Punkt am Ende eines Ordnernamens löschen zu müssen. Das ging via
cmdline nur mit der \\?-Notation.
Thorsten
Thorsten Albrecht
Dec 12, 2016, 4:04:31 PM12/12/16
to
Claus Reibenstein <4spame...@kabelmail.de> wrote:
>Wenn ich aber
>wissen möchte, welche versteckten Möglichkeiten Windows sonst noch
>bietet, hilft mir Google in keinster Weise.
Ohne Google war das früher wirklich schwierig, von "versteckten
>Wenn ich aber
>wissen möchte, welche versteckten Möglichkeiten Windows sonst noch
>bietet, hilft mir Google in keinster Weise.
Möglichkeiten von Produkt xyz" zu erfahren. Heutzutage mit Google ist
das doch erheblich leichter.
In Bezug zu Windows wird man doch förmlich von Informationen
erschlagen, was es alles in diesem OS gibt. Zig Bücher, zig online
Kurse, zig Webseiten zu Tipps und Tricks, und eine riesig große
Referenz im Technet bzw. MSDN. Wenn Du wirklich nach weiteren
Möglichkeiten in Windows suchst, hast Du eher ein "Aussuchproblem" als
ein "Findeproblem".
Aber bezogen auf \\?: Keine Ahnung, wo einem diese Info didaktisch
nahegebracht wird. Vermutlich am ehesten in einem Buch oder Kurs über
Server und Dateifreigaben oder Schattenkopien. Also Themata, die eher
nichts mit einem Endanwender zu tun haben, sondern eher mit einem
Admin.
BTW Beim Befehl 'mountvol' kommt man ziemlich schnell zumindest mit
diesem Präfix in Berührung. Dito bei 'vssadmin list volumes'.
Thorsten
0 new messages