Erkennung Pfadnamen länger als 255 Chr.

[maik]

ok, habe jetzt gefunden, daß die von mir gesuchte "Konfiguration" ja über die normale "Suchen" Funktion geht
aber eines hab ich noch nicht verstanden:
Ziel des ganzen war es doch, besonders lange Namen einzelner Unterverzeichnisse zu finden, oder ?
Über die Suche z.B > 50 bekomme ich jedoch alle Pfade (nicht einzelne Unterverzeichnisse) angezeigt (Gesamtlänge des Pfades ab Einstiegsverzeichnis)
War das Plugin nicht dafür gedacht, überlange Unterverzeichnisnamen zu finden ?

[Lefteous]

2maik

ok, habe jetzt gefunden, daß die von mir gesuchte "Konfiguration" ja über die normale "Suchen" Funktion geht

ich hatte Dich zunächst so verstanden, dass Du gerne in der Normalansicht nur dann die Pfadlänge angezeigt bekommen möchtest, wenn diese eine bestimmte Länge überschreitet. Aber natürlich ist die Suchfunktion hierbei das richtige Hilfsmittel.

Ziel des ganzen war es doch, besonders lange Namen einzelner Unterverzeichnisse zu finden, oder ?
Über die Suche z.B > 50 bekomme ich jedoch alle Pfade (nicht einzelne Unterverzeichnisse) angezeigt (Gesamtlänge des Pfades ab Einstiegsverzeichnis)
War das Plugin nicht dafür gedacht, überlange Unterverzeichnisnamen zu finden ?

Nein es ging, wie der Titel des Threads vermuten lässt, immer um die gesamte Pfadlänge. Die Länge einzelner Unterverzeichnisse ist eigentlich auch garnicht kritisch. Ich kann das aber gerne mal auf die Wunschliste setzen.

[Lefteous]

Ich habe gerade mit Erschrecken feststellen müssen, dass Microsoft Office XP keine Dateien öffnen kann, deren Pfadlänge größer als 220 Zeichen beträgt -> Argh, was für ein Bug!
Muss ich jetzt auf Office 2003 upgraden?
OpenOffice 1.10 öffnet die Datei anstandslos. Hier scheint die Grenze höher zu liegen.

[MichelPy]

Ich habe gerade mit Erschrecken feststellen müssen, dass Microsoft Office XP keine Dateien öffnen kann, deren Pfadlänge größer als 220 Zeichen beträgt -> Argh, was für ein Bug!

es ist kein Bug aber eine künstliche Limit von Explorer.
(habe das gerade im letzten C't gelesen)

du kannst aber mit SUBST X: C:\pfad1\pfad2\pfad3\etc\
auf die unerreichbare Unterverzeichnisse greifen (via pseudo X: Laufwerk)

[Lefteous]

2MichelPy

es ist kein Bug aber eine künstliche Limit von Explorer.

Hast Du mal den ganzen Thread gelesen? Schon aus der Schilderung "mit Openoffice geht es und mit MS Office nicht" folgt, dass es ein Bug ist.
Ich hab den Artikel in der c't gefunden. Da steht was von 255 (siehe Threadtitel) Zeichen. Der Rest der Artikels ist ziemlicher Unsinn.

Es wird behauptet NTFS kann längere Pfade als 255 Zeichen speichern, Windows würde das künstlich beschränken. Das stimmt nicht.
Dann wird ausgesagt Eclipse würde sich nicht an die Konvention halten. Aha, auf einmal ist es nur noch eine Konvention. Das nenne ich mal einen sauberen Widerspruch.
Der Hilfeansatz ist auch ganz prima. Hallo c't, wie isses mit Programmen die mit sowas umgehen können. Ihr kennt wohl keine, Pech gehabt.
Wie isses mit dem Slow Commander, kann der das nicht?

du kannst aber mit SUBST X: C:\pfad1\pfad2\pfad3\etc\
auf die unerreichbare Unterverzeichnisse greifen (via pseudo X: Laufwerk)

Sicher gibt es genug Tricks um die Datei doch mit Office zu öffnen. Klar greift man hier zu Workarounds, weiß bleibt einem auch anderes übrig. Naj oder man nimmt openoffice.

[MichelPy]

Hast Du mal den ganzen Thread gelesen?

na klar, schon am 27. Januar habe ich in diesem Thread geschrieben das man ohne dein Plug-in Pfade die länger als 255 chars ganz gut finden kann, mit standard TC Mittel

Aha, auf einmal ist es nur noch eine Konvention. Das nenne ich mal einen sauberen Widerspruch.

Nehmen wir 95% der Software wollen nicht mit Pfadname länger als 25x chars umgehen. Dann ist es ein Konvention.
Daneben sind solche Software optimal für FAT16/FAT32 Partitionen gemacht wo physich die limite bei 25x chars liegt.

es gibt sicher noch einige Software die nicht fähig sind mit die ältere Limite von 64 chars für ein Pfad umzugehen (NC zum Beispiel)
Weil ich von diese Limite damals gehört habe, habe ich auch damals dummes DOS Software entwickelt der nicht mit längeren Pfäde als 64 chars umgehen konnte...

Ich bin auch schon manchmal auf diese künstliche Grenze gestossen. Beim entpacken von Java Sources, Oracle Patches, oder Novell Service Packs. Ich benütze aber schöne Netware servers, wo man die Root von ein Laufwerk wo man will platzieren kann (Map Root Befehl). Auf Server Seite kann man sogar einstellen wieviel Unterverzeichnisse Levels erlaubt sind!

Es gibt immer solche künstliche Limite. Man muss leider damit leben und leiden.

Es ist aber richtig dass man die Programmierer informieren soll, wenn man diese künstliche Limite überschreiten möchte. Wenn genug Leute eine feature wollen, es gibt bug free APIs, und es ist physich machbar, dann sollte der Programmierer diese feature auf sein todolist nehmen...

Bei OpenOffice ist es einfach, jemand hat schon den Source Code klug gemacht. Bei MS Office kannst du nur hoffen...

[ghisler(Author)]

Es ist nicht nur eine Konvention: Die Dateifunktionen für ANSI-Dateinamen kommen nur mit Namen bis max 259 Zeichen zurecht, die für Unicode brauchen spezielle "Verrenkungen" für längere Namen (Voranstellen spezieller Zeichen \\?\), und können dann den Pfad nicht mehr auf Gültigkeit testen.

[Thorz]

2Lefteous:

I was linked to this thread from your TC homepage. Is there a way to know what does the plugin "Long names filesystem" do in english?

Thanks.

[icfu]

It shows length of pathnames.
This plugin is obsolete since the new content plugins. If you need to count length of path names use http://www.totalcmd.net/plugring/wdx_Filename_ChrCount.html instead and make a custom column, much more convenient.

Icfu

[Lefteous]

2Thorz
Yes the plugin is really obsolote now. It is a filesystem plugin that uses the size column to display the path length.
I will remove this plugin soon...although the concept of "overwriting" columns is quite funny...

Please use the above mentioned content plugin.

[Thorz]

Thanks