MUT: seit wann haben Ordnernamen Dateierweiterungen???

[gdpr deleted 6]

Ist ja eigentlich auch in vielen Situation praktisch, dass der TC auch bei Verzeichnisnamen Erweiterungen annimmt, obwohl Verzeichnisse ja im Grunde genommen keine haben. Obwohl ich dieses Verhalten recht praktische find, so gibt es halt leider auch Situationen, wo es unpraktisch ist - wie Holde's Problem eben. Ich habe ehrlich gesagt aber auch keine Ahnung, wie man dies zur Zufriedenheit aller loesen kann...

[milo1012]

Der Punkt (), den hier alle offenbar uebersehen, ist, dass bei Dateinamen der Bestandteil hinter dem letzten Punkt (Punkt inklusive) als Erweiterung angesehen wird. Bei DATEInamen, nicht bei Verzeichnisnamen. Die Dinger heissen ja deshalb auch DATEIerweiterungen; Verzeichniserweiterungen gibt's nicht. Der Begriff "Erweiterung" ist ja nur eine Kurzform fuer "Dateierweiterung".

Tja, nur gut, dass Verzeichnisse historisch gesehen, also unter DOS und mit 8.3-Namenskonvention, nichts weiter als Dateien mit Zusatzeintrag waren, dementsprechend also die selben Namenskonventionen galten.
Wie es unter anderen Systemen war, z.B. im klassischen UFS, ist mir nicht völlig klar, aber so weit ich weiß war es lange Zeit auch nur eine Datei mit speziellen Flags. (vielleicht hier nachzulesen)

Oder anders ausgedrückt:
Wenn man von Dateinamen spricht, meint man i.d.R. auch die Namen von Verzeichnissen/Ordnern, inklusive deren Beschränkungen (Limitierung auf 255 Zeichen, Zeichenkodierung, verbotene Zeichen, etc.).
Mir ist jedenfalls kein Dateisystem bekannt, dass nach Verzeichnissen und Dateien in den Namenskonventionen unterscheidet, denn für die Dateisystem-Ebene ist es immer die selbe Konvention. So gesehen ist es eher kontraproduktiv, wenn TC das Verhalten plötzlich ändern würde.

Man könnte jetzt lange diskutieren, ob es heute mit langen Dateinamen sinnvoll ist, so eine Unterscheidung zu treffen, aber mich hat das Verhalten im TC diesbezüglich nie gestört.
Eine Option wäre aber sicherlich möglich, z.B.:
[x] Dateiendung bei Verzeichnissen als Teil des Namens interpretieren.

Bliebe nur die Frage, wohin mit so einer Option (Hauptmenü, direkt ins MRT, nur als Ini-Option).

[gdpr deleted 6]

Tja, nur gut, dass Verzeichnisse historisch gesehen, also unter DOS und mit 8.3-Namenskonvention, nichts weiter als Dateien mit Zusatzeintrag waren, dementsprechend also die gleichen Namenskonventionen galten.
Wie es unter anderen Systemen war, z.B. im klassischen UFS, ist mir nicht völlig klar, aber so weit ich weiß war es lange Zeit auch nur eine Datei mit speziellen Flags. (vielleicht hier nachzulesen)Bliebe nur die Frage, wohin mit so einer Option (Hauptmenü, direkt ins MRT, nur als Ini-Option).

Wieso bringst du jetzt Aspekte von Dateisystemen ins Spiel? Dateierweiterungen sind sind ein Konzept dass nur bei hoeheren Funktionen des OS und bei Applikationen eine Rolle spielt.

Dateierweiterungen und Dateisysteme haben nichts miteinander zu tun. Auf Dateisystem-Ebene gibt es das Konzept von Dateierweiterungen ueberhaupt nicht. Wie du eine Verbindung zwischen Implementierungsdetails von Datei-/Verzeichnis-Objekten auf Dateisystem-Ebene und dem Konzept von Dateierweiterungen ziehen kannst, ist mir schleierhaft.

Mir ist jedenfalls kein Dateisystem bekannt, dass nach Verzeichnissen und Dateien in den Namenskonventionen unterscheidet, denn für die Dateisystem-Ebene ist es immer die gleiche Konvention. So gesehen ist es eher kontraproduktiv, wenn TC das Verhalten plötzlich ändern würde.

Noch einmal: Namens-Konventionen sind dem Dateisystem komplett schnuppe. Bzgl. Namen legen Dateisysteme nur fest, wie lang ein Name eines Objektes maximal sein kann und welche Zeichen (wenn ueberhaupt) erlaubt sind. Desweiteren gibt es noch Regeln bzgl. resevierter/spezieller Namen als auch der Organisation von FS-Objekten (z.B. Objekte in einem Verzeichnis oder aehnlichem -- bitte jetzt keine Diskussion darueber wie Verzeichnisse in NTFS zb. realisiert sind -- duerfen nicht den gleichen Name haben -- was aber uebrigens auch nicht bei jedem FS so ist)

Ansonsten stimme ich natuerlich zu, dass eine Aenderung des Verhaltens von TC fuer viele unerwuenscht ist.

[HolgerK]

Es gibt keine unterschiedlichen Verzeichnisformate, also gibt's bei Verzeichnissen keinen Grund sie nach Verzeichnisformate unterscheiden zu wollen. Was dann auch dazu fuehrt, dass es eben keine Verzeichniserweiterungen bei Windows gibt

Wobei, eigentlich gibt's bei Windows so etwas aehnliches wie Verzeichniserweiterungen. Gewisse jedenfalls... Hoffentlich sind jetzt alle mal richtig durcheinander Probiert doch mal was bei http://superuser.com/a/593514/274116 beschrieben ist (laesst sich mit TC schnell und einfach bewerkstelligen). Voila...

<OT>
Nun ist zwar etwas offtopic, aber Verzeichnisformate kann man schon recht gut einsetzen, bzw. selektiv festlegen, welche Verzeichnisse mit welchem Programm geöffnet werden sollen.

Die Verknüpfung erfolgt dann zwar nicht über ein Verzeichniserweiterung sondern über eine Kombination aus Customized Folder + Desktop.Ini-Eintrag und einer Verzeichnisassoziation in der Registry.

Damit man mal den praktischen Nutzen abschätzen kann:
Viele TC + Firefox Anwender haben sich bestimmt schon irgendwelche Workarounds überlegt um das Downloadverzeichnis aus dem Firefox heraus direkt im TC zu öffnen.

Step By Step Anleitung(Adminrechte vorausgesetzt):
- Im Download Verzeichnis (üblicherweise "C:\Users\<Name>\Download" befindet sich eine Desktop.ini (weil er bereits customized ist) in der man unterhalb der Sektion [.ShellClassInfo] eine Zeile mit

Code: Select all

DirectoryClass=OpenFolderWithTC

hinzufügt.

Dann den folgenden Registry-Script anpassen und ausführen:

Code: Select all

REGEDIT4

[HKEY_CURRENT_USER\Software\Classes\OpenFolderWithTC]
"CanUseForDirectory"=dword:00000000

[HKEY_CURRENT_USER\Software\Classes\OpenFolderWithTC\shell]
@="OpenWithTC"

[HKEY_CURRENT_USER\Software\Classes\OpenFolderWithTC\shell\OpenWithTC]
@="Open with Total Commander"

[HKEY_CURRENT_USER\Software\Classes\OpenFolderWithTC\shell\OpenWithTC\command]
@=""C:\\Tools\\totalcmd\\TOTALCMD64.EXE" "%1""

- Den Menüeintrag im Zweig OpenWithTC kann man natürlich auch in Deutsch angeben.
- Der Pfad in der letzten Zeile muss an den Pfad der TC Installation angepasst werden.

Anstelle von "HKEY_CURRENT_USER" kann man das auch direkt unter "HKEY_LOCAL_MACHINE" eintragen; dann gilt es nicht nur für den aktuellen Benutzer sondern für alle Benutzer.

-> Fortan wird ein Doppelklick im Explorer auf das Downloadverzeichnis dieses dann im TC öffnen (und noch besser: das Kontextmenü im Firefox ebenfalls
</OT>

Gruss
Holger

[milo1012]

Dateierweiterungen sind sind ein Konzept dass nur bei hoeheren Funktionen des OS und bei Applikationen eine Rolle spielt.

Dateierweiterungen und Dateisysteme haben nichts miteinander zu tun. Auf Dateisystem-Ebene gibt es das Konzept von Dateierweiterungen ueberhaupt nicht.

Auf FAT aber schon, wie oben verlinkt, und DOS/Win 3.1 hatten im Prinzip keine weitere Schicht zwischen Dateisystem und Präsentationsfläche, das Dateisystem war die Präsentationsfläche.
TC und Windows sind auf diesen Systemen groß geworden, haben also diese Konzepte übernommen.
Dass bei NTFS und Co. heutzutage mindestens eine Abstraktionsebene dazwischen liegt, steht natürlich außer Frage, die Regeln sind aber eben geblieben.

Wie du eine Verbindung zwischen Implementierungsdetails von Datei-/Verzeichnis-Objekten auf Dateisystem-Ebene und dem Konzept von Dateierweiterungen ziehen kannst, ist mir schleierhaft.

Und mir ist schleierhaft, wieso du ein einfaches Argument nicht nachvollziehst.
Mein Punkt war einfach nur der, dass ein Dateiname für Verzeichnisse eben immer noch ein "Dateiname" ist. Dementsprechend wendet man in erster Linie die gleichen Regeln an.
Du warst derjenige, der behauptet hat, dass der Bestandteil hinter dem letzten Punkt "Bei DATEInamen, nicht bei Verzeichnisnamen" als Erweiterung angesehen wird.
Dass eine Namens-Erweiterung für Verzeichnisse (in den meisten Fällen) sinnfrei im Bezug auf die Shell-Abstraktion "Öffne diesen Typ mit..." ist, ist eine ganz andere Frage, ändert aber nichts daran, dass man die Unterscheidung nach Name und Erweiterung in vielen Fällen trotzdem anwendet, um z.B. besser sortieren zu können.

Nur so als Beispiel:
Chkdsk legt nach wie vor Verzeichnisse
found.000
found.001
an, obwohl man sie ja auch
found000
found001
nennen könnte.

[gdpr deleted 6]

Auf FAT aber schon, wie oben verlinkt, und DOS/Win 3.1 hatte im Prinzip
keine weitere Schicht zwischen Dateisystem und Präsentation, das Dateisystem war die Präsentationsfläche.

Der Link spricht ueber "DOS filenames". DOS != FAT. Das eine ist ein (rudimentaeres) OS, das andere ist ein Dateisystem.

TC und Windows ist auf diesen Systemen groß geworden, haben also diese Konzepte übernommen.
Dass bei NTFS und Co. heutzutage mindestens eine Abstraktionsebene dazwischen liegt, steht natürlich außer Frage, die Regeln sind aber eben geblieben.

Wenn du dich auf die Korrektheit dieses MS-Artikels verlaesst, dann ist es verstaendlich dass du dich schwer tust. Leider ist dieser Artikel ein bisschen verkehrt herum geschrieben und hat das selbe Problem wie du (Darstellung von OS-Features als FS-Features und andersrum; na ja, kann ja mal passieren). Was wohl gemeint ist: Windows (also das OS) folgt den immergleichen Namenskonventionen fuer Pfade und Namen, egal welches Dateisystem es benutzt. Interessant ist aber, dass der Artikel tatsaechlich von Erweiterungen fuer sowohl Dateien als auch Verzeichnissen spricht. Klingt danach, als ob MS tatsaechlich irgendwann mal in Erwaegung gezogen hat, irgendwas vernuenftiges mit "Verzeichniserweiterungen" zu realiseren.

Mein Punkt war einfach nur der, dass ein Dateiname für Verzeichnisse eben immer noch ein "Dateiname" ist. Dementsprechend wendet man in erster Linie die gleichen Regeln an.

Es stimmt zwar, dass du da einen Artikel bei MS gefunden hast, der ueber Erweiterungen fuer sowohl Dateien als auch Verzeichnissen spricht. Nicht, dass dies der erste Artikel waere, der einer Ueberarbeitung beduerfte. Der Punkt ist doch dieser: Wir reden hie von einem Konzept und ob/wie dies im OS (bzw. Applikationen) realisiert ist. Genauer reden wir hier von High-Level-Funktionen (APIs des OS, die von den meisten Applikationen, egal ob MS- oder 3rd-Party-Applikationen verwendet werden) als auch Bedienkonzept(en). Tatsaechlich ist es so, dass sowohl beim Bedienkonzept als auch bei den high-level Funktionen/APIs Dateien und Verzeichnisse unterschiedliche Dinge darstellen. Und dass das OS zahlreiche Funktionalitaeten anbietet, die "irgendwas Sinnvolles" basierend auf Dateierweiterungen machen. Und dass Verzeichniserweiterungen nicht bekannt sind / das Konzept von Verzeichniserweiterungen defacto nicht vom OS und den allermeisten Applikationen realisiert ist.

Du warst derjenige, der behauptet hat dass der Bestandteil hinter dem letzten Punkt "Bei DATEInamen, nicht bei Verzeichnisnamen" als Erweiterung angesehen wird.

Richtig. Allerdings ist dies nicht nur eine Behauptung von mir. Nicht nur die Existenz dieses Threads sollte dir das klarmachen (ausser dies ist heute dein erster Tag an einem PC... )

Dass eine Namens-Erweiterung für Verzeichnisse (in den meisten Fällen) sinnfrei im Bezug auf die Shell-Abstraktion "Öffne diesen Typ mit..." ist, ist eine ganz andere Frage, ändert aber nichts daran, dass man die Unterscheidung nach Name und Erweiterung in vielen Fällen trotzdem anwendet, um z.B. besser sortieren zu können.

Vielleicht habe ich mich in Bezug auf dieses tatsaechlich etwas unklar ausgedrueckt. Mir ging es nicht darum, Verzeichniserweiterungen als eine sinnlose Sache darzustellen, sondern eher darzulegen, dass das Konzept von Verzeichniserweiterungen (oder eben das Konzept von Erweiterungen fur sowohl Dateien als auch Directories) bislang als nicht notwendig erachtet wurde/wird nicht zuletzt bei den jeweiligen OS-Entwicklern. Andererseits wird das Konzept von Dateierweiterungen schon seit sehr, sehr langer Zeit von verschiedensten OS (OS != FS !!!) verwendet und stellt nicht zuletzt auch bzgl. vieler ueblicher Dateierweiterungen fuer gewisse allgemeinbraeuchliche Dataeiformate einen Defacto-Standard da, der mehr oder weniger fast ueberall angewandt wird.

[milo1012]

DOS != FAT. Das eine ist ein (rudimentaeres) OS, das andere ist ein Dateisystem.

Öhm...
DOS (MS- und IBM-DOS), auch schon die ersten Versionen, war auf FAT aufgebaut, kann und konnte ohne Zusatzprogramme auch nichts anderes benutzen.
Das lässt sich auch in vielen Datenformaten von heutigen API-Funktionen nachvollziehen, z.B. FileTimeToDosDateTime, was mit einer 2-Sekunden-Genauigkeit beim Änderungsdatum arbeitet, eben genau wie FAT (egal ob FAT12, -16, oder -32). Ich werde das jetzt nicht noch weiter vertiefen.

Leider ist dieser Artikel ein bisschen verkehrt herum geschrieben und hat das selbe Problem wie du (Darstellung von OS-Features als FS-Features und andersrum; na ja, kann ja mal passieren).

Schon mutig, so etwas in diesen Artikel hinein zu interpretieren.
Nein, der Artikel bezieht sich klar auf das, was ich oben versucht habe zu erklären. Du solltest das Ganze (inklusive der Beschränkungen) einfach historisch betrachten, und nicht vom theoretischen Standpunkt einer allgemeinen Aussage aus.

Wir reden hie von einem Konzept und ob/wie dies im OS (bzw. Applikationen) realisiert ist.

Ja und? Ich habe lediglich versucht zu erklären, WARUM die Namenskonventionen bei Windows heute so sind wie sie sind, und dass man sich nicht wundern sollte, warum TC diese Unterscheidung nach Name/Erweiterung macht.

Tatsaechlich ist es so, dass sowohl beim Bedienkonzept als auch bei den high-level Funktionen/APIs Dateien und Verzeichnisse unterschiedliche Dinge darstellen..

Du scheinst zu überlesen, wie Ich dir versuche zu erklären, dass ein Verzeichnis auf Windows gar nicht so unterschiedlich zu einer Datei ist.
Die Erklärung mit FAT diente nur dazu, um zu verdeutlichen, wie das Ganze historisch gewachsenen ist, und warum heutzutage immer noch eine Unterscheidung nach Name/Erweiterung gemacht wird (Stichwort "Abwärtskompatibilität").
Ich habe selbst einschlägige Erfahrung mit der Win-API, und so unterschiedlich sind Dateien und Verzeichnisse dort gar nicht behandelt. Beispielsweise muss ich bei FindFirstFile immer noch mühsam mit Attributen prüfen, was ich überhaupt gefunden habe.

Richtig. Allerdings ist dies nicht nur eine Behauptung von mir. Nicht nur die Existenz dieses Threads sollte dir das klarmachen (ausser dies ist heute dein erster Tag an einem PC...)

Na na, bitte nicht kokettieren. Meine Antworten bezogen sich nur auf deine Aussage(n).
Ich weiß nicht was dich hier qualifiziert, deine Aussagen als allgemeingültig hinzustellen, aber ich denke, wir sind beide in der IT tätig. Gerade dann solltest du aber vielleicht nicht mit Dingen argumentieren, gegen die der Nächstbeste aus der Branche durch eine gegenteilige Erfahrung Einwände hätte.

Mir ging es nicht darum, Verzeichniserweiterungen als eine sinnlose Sache darzustellen, sondern eher darzulegen, dass das Konzept von Verzeichniserweiterungen (oder eben das Konzept von Erweiterungen fur sowohl Dateien als auch Directories) bislang als nicht notwendig erachtet wurde/wird nicht zuletzt bei den jeweiligen OS-Entwicklern

Was führt dich zu dieser Annahme? Ich vermute, du arbeitest seit 30 Jahren als IT-Berater und OS-Programmierer, um es ganz genau zu wissen.
Ich habe z.B. nicht gerade wenig Programme installiert, welche bei "ihren" Verzeichnissen, völlig egal ob nun für gespeicherte Konfiguration oder die Programmmodule selbst, Erweiterungen benutzen.
Und wieso benutzt TC dann eben trotz dieser Annahme die Erweiterung getrennt im MUT? Da beißt sich die Katze in den Schwanz...

Andererseits wird das Konzept von Dateierweiterungen schon seit sehr, sehr langer Zeit von verschiedensten OS (OS != FS !!!) verwendet und stellt nicht zuletzt auch bzgl. vieler ueblicher Dateierweiterungen fuer gewisse allgemeinbraeuchliche Dataeiformate einen Defacto-Standard da, der mehr oder weniger fast ueberall angewandt wird.

Das habe ich auch nirgendwo dementiert, sondern nur darauf hingewiesen, dass die Regeln für Dateinamen auch bei Verzeichnissen Anwendung finden, ergo eine Erklärung für das in meinen Augen korrekte Verhalten im MUT.



P.S. es wäre schön, wenn du deine Antworten nicht ständig überarbeiten würdest, so dass ich auch die richtigen Stellen quoten kann

[ZoSTeR]

Extensions für Ordner widersprechen der Nutzererwartung (Behauptung!) als auch .NET bzw. PowerShell:

"Ordner.mit.Punkten"
[System.IO.DirectoryInfo].Extension = ""

"Datei.mit.Punkten"
[System.IO.FileInfo].Extension = ".Punkten"