Win7: Punkt am Anfang eines Dateinamens

Klaus schrieb:
> Wie kann man eigentlich unter Win7 eine Datei mit Punkt am Anfang
> erstellen?

Wie hast du es versucht?

Klaus schrieb:
> Ich möchte habe hier eine eclipse Projekt-Datei, die ich in .project
> umbenennen muss.

Umbenennen geht einwandfrei. Habe hier allerdings auf dem Win 7 Rechner 
Admin Rechte.
Vieleicht geht es nicht im Datei Explorer, in der kommandozeile aber 
ohne Probleme.

Nachtrag: Auch der free commander macht das ohne Murren.

Der Explorer erlaubt einen Punkt am Anfang des Dateinamens -- wenn der 
Dateiname eine Extension enthält, also ein zweiter Punkt vorhanden ist:

.bla.txt

Offensichtlich sind die Organismen, die bei MS den Explorer entwickeln, 
der Ansicht, daß eine Datei entweder einen Namen mit Extension, oder 
einen Namen ohne Extension, aber nie nur eine Extension haben kann -- 
das ist halt die Schleppscheiße aus der 8.3-Gedankenwelt mit dem Konzept 
der Extension (MS-Deutsch: Dateinamenerweiterung).

Dateien ohne Extension können im "Eingabeaufforderungsfenster"* so 
genannt werden:

1

ren bla.txt .blafusel

*) das ist das, was viele fälschlich "DOS-Fenster" oder "DOS-Box" nennen

Ich hab es gerade auf 'cmd' versucht und es funktioniert.

cp bla.txt .bla.txt
cp bla.txt .bla

Gruß aus Berlin

Rufus Τ. Firefly schrieb:
> Dateien ohne Extension können im "Eingabeaufforderungsfenster"* so
> genannt werden:

Nenn es soch einfach Kommandozeile :-)

Diese Krankheit ist nicht auf Windows 7 beschränkt, das ist beim 
Explorer schon länger (immer?) so.

Klaus schrieb:
> Dann würde ich das Update nämlich
> gerne der IT zurückgeben ;-)

Was kann eure IT dafür, selbst wenn es so wäre?

Klaus schrieb:
> Und unter XP ist das doch meines Wissens
> nicht so.

Nö, auch unter XP verhält sich der Explorer so.

Dateinamen dürfen nur dann mit einem Punkt anfangen, wenn sie einen 
zweiten Punkt enthalten (und der darf nicht unmittelbar auf den ersten 
folgen).

... und viele Programme aus der Unix-Welt sind mehr schlecht als recht 
nach Windows portiert worden.

nicht "Gast" schrieb:
> und wie das Windowsgebashe schon wieder los geht

Keiner hat hier gebasht. Nur die Windows Jünger wie du fühlen sich schon 
mal vorab auf den Schlips getreten.
Und wenn du den Dateiexplorer göttlich verehren willst tust du mir leid.

nicht "Gast" schrieb:
> Es ist einfach eine Designentscheidung gewesen
Aber eine von Dos. Spatestens 2.0.

Der Rächer der Transistormorde schrieb:
> Was ja wenig relevant ist da Windows hidden files über Attribute regelt.

Tja, es gibt halt auch eine Welt außerhalb eures Windows Tellerrands. 
Und warum sollten betriebssystemübergreifende Programme die Dateien 
unterschiedlich benennen müssen?
Btw. Es war schon geklärt daß sie das gar nicht müssen, weil nur die 15 
Jahr alte Anwendung Datei Explorer an der Stelle etwas blöde ist.

Der Rächer der Transistormorde schrieb:
> Das ist genau so hirnlos wie die GroßKleinSchreibUng bei UNOX Systemen

Hirnlos sind eher Dinge wie Blanks in Dateinamen und Pfaden.
Und Erlauben von Groß Kleinschreibung ist genauso ein Mist. Man muss 
beim Vergleich immer auf ignore Case gehen.
Und das geht mit Unicode und zum Beispiel türkischen Sonderzeichen 
(unterschiedliche 'i') sowas von in die Hose.

Scheiße wurde und wird überall verzapft, nur wer nichts macht macht auch 
nie Mist.

Udo Schmitt schrieb:
> Und warum sollten betriebssystemübergreifende Programme die Dateien
> unterschiedlich benennen müssen?

Zur Portierung eines Programmes gehört es, das Programm an die 
Gepflogenheiten des Betriebssystems anzupassen, auf die es portiert 
wird.

Und wenn die Gepflogenheiten auch noch so schwachsinnig erscheinen mögen 
(oder meinetwegen auch sind), es gehört einfach dazu.

Der Rächer der Transistormorde schrieb:

>> Und warum sollten betriebssystemübergreifende Programme die Dateien
>> unterschiedlich benennen müssen?
>
> Was ist denn ein betriebssystemübergreifendes Programm?

Warscheinlich meint er ein Skriot wie PHP das in der tat auf beiden 
Systemen läuft (laufen kann) und seine eigenen Dateibehandlungen 
wünscht.

Der Rächer der Transistormorde schrieb:
> Schätze mal das ist bei UNOX nicht anders.

Das einzig kommerziell erfolgreiche Desktop-UNIX* erlaubt Slashes beider 
Art im Dateinamen, und selbstverständlich auch Leerzeichen und 
wasnichtalles. Doppelpunkte allerdings werden abgelehnt.


*) OS X.

Rufus Τ. Firefly schrieb:
> Klaus schrieb:
>> Und unter XP ist das doch meines Wissens
>> nicht so.
>
> Nö, auch unter XP verhält sich der Explorer so.
>
> Dateinamen dürfen nur dann mit einem Punkt anfangen, wenn sie einen
> zweiten Punkt enthalten (und der darf nicht unmittelbar auf den ersten
> folgen).

...

Do not end a file or directory name with a space or a period. Although 
the underlying file system may support such names, the Windows shell and 
user interface does not. However, it is acceptable to specify a period 
as the first character of a name. For example, ".temp"

http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#naming_conventions

> Kurzum, bei Windows gibt es Dateinamen und Dateiendungen,
> die eine Aussage über den Typ der Datei geben sollen...

Darin liegt ja der Murx von Windows. Der Type der Datei steht in der 
Datei!
Sonst nix.

Deshalb haben die jetzt auch zwei Möglichkeiten "FORMAT.COM" ist heute 
eine URL und gleichzeitig ein ausführbares Programm.

Wie blöd ist das denn.

Wer denkt, dass Windows bei Dateinamen nicht zwischen Groß- und 
Kleinschreibung unterscheidet, hat etwa zwei Jahrzehnte 
Windows-Neuerungen nicht mitbekommen. ;-)

Der Rächer der Transistormorde schrieb:
> Der Slash und Backslash sind übrigens immer noch nicht im Dateinamen
> möglich.
>
> Schätze mal das ist bei UNOX nicht anders.

Es gibt nur zwei Zeichen die unter Unix nicht in einen Dateinamen gehen: 
der Slash (weil das der Pfad-Separator ist) und das NUL-Byte (weil es 
das Ende eines Strings kennzeichnet). Ob es sinnvoll ist, das eine oder 
andere (Sonder-)Zeichen in einem Dateinamen zu verwenden, ist 
Ansichtssache. Man tut gut daran, die althergebrachten Konventionen 
seines Betriebssystems zu kennen und einzuhalten. Es senkt die 
Wahrscheinlichkeit unangenehmer Überraschungen.

W.S. schrieb:
> Und hier will nun jemand
> partout nen Dateinamen kreieren, der nur aus Endung besteht. Ist nur
> Mutwillen ohne wirklichen Sinn dahinter.

Ich könnte dir rechtgeben, wenn sich die Windows-Kommandozeile so wie 
der Explorer verhalten würde.

W.S. schrieb:
> Kurzum, bei Windows gibt es Dateinamen und Dateiendungen, die eine
> Aussage über den Typ der Datei geben sollen. Es gibt hier übrigens auch
> Laufwerksbuchstaben, anhand derer man verschiedene Speichervolumina
> unterscheiden kann. Kennt man in der Unox-Welt auch bloß nicht.

Unter Unix nicht nötig, beides. Letzteres ist auch unter Windows nicht 
nötig.

Zum Thema versteckte Dateien in Unix und unixähnlichen Betriebssystemen:
https://plus.google.com/101960720994009339267/posts/R58WgWwN9jp

Sebastian schrieb:
> Beim Versuch
> sie zu löschen kommt mir Windows damit dass die Datei gar nicht
> existiere !!!!

Der Explorer ist für manches zu blöde. Oft hilft es, den 8.3-Namen 
anzeigen zu lassen und darüber zu löschen, also schön ein 
Kommandozeilenfenster aufmachen, dir /x eintippen und probieren ...

Allerdings gibt es Vorgaben, wie Dateinamen für das Dateisystem 
beschaffen zu sein haben. Und wenn Software sich nicht an diese Vorgaben 
hält, ist die Software fehlerhaft, hier also das make, das ungültige 
Dateinamen erzeugt.

Reinhard Kern schrieb:
> Unix muss man die Datei erst öffnen, lesen und und in endlosen Listen
> magische Zahlen nachschlagen

Und das war die zweitdümmste... Kenner fragen einfach das Programm 
"file". Das kennt sehr viele dieser Zahlen und Listen nämlich schon.

Hat gegenüber der Extension den Vorteil, dass man ein ausführbares File 
auch dann als Solches erkennt, wenn es sich unter diversen anderen 
Extensions tarnt. Windows startet nämlich auch diverse andere Extensions 
als EXE, wenn es anhand des Inhalts erkennt, dass es eigentlich ein EXE 
sein müsste. Bei Trojaner-Autoren war schon früh .LNK beliebt.

Effektiv wäre, wenn Windows ein in .LNK umbenanntes .EXE nicht einfach 
starten würde. Denn auf Links klickt dein DAU natürlich drauf, selbst 
wenn er pfiffig genug ist, es bei .EXE nicht zu tun. Und effektiv wäre 
auch, wenn die Extension tatsächlich angezeigt würde, was Windows in 
Standardeinstellung bis heute nicht tut.

Peter II schrieb:
> der DateiType muss (sollte) irgendwo an der Eigenschaft der Datei stehen
> und sich nicht erst über den inhalt ermitteln lassen. Und da ist eine
> erweiterung mit . eine sinnvolle Lösung.

Ja. Aber eben nur wenn man das konsequent so macht und es dem Anwender 
konsequent und sichtbar vor Augen führt. Und genau das macht keiner. 
Windows auch nicht.

Peter II schrieb:
> viel Spass bei 1.000.000 dateien wo ein JPG versteckt ist und alles
> andere andere Formate sind.

JPEGs sind auch in Linux nicht ausführbar. Und auch Linux Dateimanager 
verwenden für Bilder die Extension. Mehr gibts da nämlich auch nicht. 
Also wo ist das Problem?

Was ich an "file" schön finde: Es sagt mir, was von der Signatur her 
tatsächlich drin ist. Nicht einfach, was draufsteht. Ist dir noch nie 
ein JPG begegnet, das sich als GIF herausstellte? Ist insbesondere als 
Basis für automatischs Checks sehr hilfreich.

Es gab auch mal andere Ansätze. Nämlich ein separates nicht direkt 
sichtbares Attribut, was das File einer Anwendung zuordnete. An sich 
eine nette benutzerfreundliche Idee. Derart benutzer- und 
trojanerfreundlich, dass der Benutzer keinen Schimmer hatte, was 
passieren wird, wenn er drauf klickt. Sowas hatte OS/2 beispielsweise im 
Angebot, aber ich meine mich zu erinnern, dass auch Apple diese Idee 
nicht fremd war.

Das ändert nichts daran, dass die Extension die Information "Typ der 
Datei" oftmals* redundant (da aus dem Inhalt schon ersichtlich) 
speichert. Und damit eine Steilvorlage für mögliche Inkonsistenzen 
zwischen behauptetem und tatsächlichem Typ bietet.

Ob es nun sinnvoller ist, diese Redudanz in Kauf zu nehmen oder jedes 
Mal in der Datei herumzuwühlen, ist sicherlich Geschmackssache.
Wenn es nur um die Performance geht, kann man sowas ja auch prima in 
anderen und nicht durch bloße Umbenennung zerstörbaren Metadaten 
ablegen, auch mit automatischer Aktualisierung bei Änderung des Inhalts.

*) Bei einigen Dateitypen kann der Typ wiederum nicht anhand weniger 
Magic Numbers etc. ermittelt werden. Ob eine Text-Datei jetzt Quellcode 
ist oder Prosa mit Quellcode am Anfang, erfordert schon eine 
gründlichere Analyse. Und in welcher natürlichen oder Maschinensprache 
ist der Text jetzt?
Auch gibt es den einen oder anderen binären Dateityp, der aus Kurzsicht 
(z.B. .ico) oder prinzipbedingt (Rohe Audio-/Bild-/Videodaten, 
µC-Binaries...) keine vernünftig auswertbaren Magic Numbers bietet.
DA ergibt eine Extension durchaus Sinn, auch wenn man sich sonst auf die 
Inhaltsbetrachtung verlässt.
Ist alles nicht so schwarz/weiß wie man manchmal vielleicht gerne 
möchte.

Atomjupp schrieb:
> warum muss man Dateinamen mit Punkt am Anfang verwenden?

Das braucht man in Dateisystemen, die kein zusätzliches 
"hidden"-Attribut haben.

Rufus Τ. Firefly schrieb:
> Zur Portierung eines Programmes gehört es, das Programm an die
> Gepflogenheiten des Betriebssystems anzupassen, auf die es portiert
> wird.
>
> Und wenn die Gepflogenheiten auch noch so schwachsinnig erscheinen mögen
> (oder meinetwegen auch sind), es gehört einfach dazu.

das führt am Ende aber dazu, dass Projekte, die auf dem einen System 
erzeugt wurden, auf einem anderen nicht verwendbar sind.

Beispiel 1: SVN
Ich zieh mir unter Windows ein Repo, welches unter Linux nicht mehr 
verwaltbar wäre, weil mit dem Hidden-Attribut anstatt dem Punkt am 
Anfang gearbeitet wurde.


Beispiel 2: wirklich portable SW
Was ist mit VM-Programmen (Java) oder Scripten, die in beiden Umgebungen 
laufen sollen?

Dann doch lieber der kleinste gemeinsame Nenner und das sind Dateinamen.
das der Explorer da querschießt ist ein wenig blöd, immerhin die OS-API 
CreateFile macht, was man ihr sagt, so dass es kein Prinzipielles 
Problem ist solche Dateien zu verwenden und zu erzeugen.

Vlad Tepesch schrieb:
> Ich zieh mir unter Windows ein Repo, welches unter Linux nicht mehr
> verwaltbar wäre, weil mit dem Hidden-Attribut anstatt dem Punkt am
> Anfang gearbeitet wurde.

Dann wäre eigentlich ein sinnvoller Weg der, das Attribut in einen 
Punkt zu übersetzen, und umgekehrt. Das müsste die 
Versionsmanagementsoftware machen, je nach dem, in welche Richtung 
Dateien übertragen werden.


Aber das ist nicht das einzige Problem; die Unterscheidung in C- und 
C++-Dateien nur anhand der Groß- und Kleinschreibung von .c / .C ist 
erst recht nicht portabel.

Du erfindest grad das Rad neu. Siehe Samba. Nicht die Bewegungsanleitung 
für Hupfdohlen, sondern den SMB-Fileserver.

Reinhard Kern schrieb:
> dazu kann man ja nicht den Server
> auf den Kopf stellen.

Vom Server war auch keine Rede, das sollte der jeweilige Client 
erledigen.

Reinhard Kern schrieb:
> Der kann aber auch nicht wissen, ob er nun auf ein Windows- oder auf ein
> Linux-Dateisystem zugreift.

Ich bin von einem Client eines Versionskontrollsystems ausgegangen, der 
nicht einfache Dateizugriffe macht. Wenn es Dir nur um simple 
Dateisystemzugriffe geht -- dann ist so etwas natürlich nicht so einfach 
möglich.

Samba setzt z.B. bei entsprechender Konfiguration das Hidden-Attribut 
um. Nicht zu einem führenden Punkt (das wäre anmaßend), aber zu einem 
Erweiterten Attribut. Sofern dieses Mapping aktiv ist, ist in diese 
Richtung ist eigentlich alles Schick.
Müsste halt der CIFS-Client des Linux-Kernels auf dem gemounteten System 
das Hidden-Attribut für alle Dotfiles setzen, AFAIK passiert das nicht. 
Und Dotfiles wären es immer noch.

W.S. schrieb:
> btw: gibt es bei Unix eigentlich noch andere stille Vereinbarungen
> dieser Art, also z.B. spezielle Textzeichen für readonly usw?

Nein, dafür gibt es klassische Zugriffsrechte und ACLs, wie bei NTFS 
auch, wo das alte "readonly"-Attribut auch nicht mehr so wirklich eine 
Daseinsberechtigung hat.
Zur Klarstellung: Führender Punkt = versteckt ist sicherlich nicht das 
beste seit geschnitten Brot. Eine direkte Katastrophe ist es aber auch 
nicht.

W.S. schrieb:
> Allerdings ist die
> Windows-Version besser weil portabler: Da wird der Dateiname wenigstens
> nicht mit Zeichen verhunzt, die nur für Unix eine verständliche
> Neben-Bedeutung haben und woanders mit dem Dateisystem kollidieren.

Eben nicht mit dem Dateisystem. Nur mit einer zur Bevormundung neigenden 
Anwendung (Explorer).

@ A. K. (prx)

>Extensions tarnt. Windows startet nämlich auch diverse andere Extensions
>als EXE, wenn es anhand des Inhalts erkennt, dass es eigentlich ein EXE
>sein müsste. Bei Trojaner-Autoren war schon früh .LNK beliebt.

Wirklich? Muß wohl nur bei alten Versionen so gewesen sein. Ich kann 
zumindest unter Win7 keine Exe, die ich von *.exe nach *.exe.lnk (oder 
sonstwas) umbenannt habe, starten. Und ich bilde mir ein, unter WinXP 
hatte ich sowas auch schon erfolglos versucht.

gerade unter XP getestet - da geht's wirklich noch:-)