Wie kann man eigentlich unter Win7 eine Datei mit Punkt am Anfang erstellen? Und was soll das überhaupt, dass MS das verhindert? Ist das schon immer so, oder kam das mit einem Update rein? Ich möchte habe hier eine eclipse Projekt-Datei, die ich in .project umbenennen muss.
Liegt wohl daran, dass Windoof denkt, dass es sich um eine Dateiendung handeln könnte und sich bei, z.B. .projekt.bin, fragt was ist denn jetzt die Dateiendung und warum macht der Anwender sowas. Evtl. funktioniert das unbenennen bei Linux.
Natürlich funktioniert das unter Linux! Da ist so ein Dateiname das normalste auf der Welt. Aber die Frage war: Wie geht das unter Windows, denn da gibt es einen Haufen Programme, die so benannte Dateien verwenden.
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.
Auch mal ausprobiert, geht tatsächlich ohne Probleme. Habe aber auch Admin Rechte.
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 :-)
Ok, danke! Ich fasse also zusammen: - Wenn es einen weiteren Punkt im Dateinnamen gibt, geht's - Umbenennen in der Kommandozeile funktioniert - Kopieren von solchen Dateien geht - Manche Programme lassen das Speichern einer solchen Datei zu, andere (natürlich MS Programme) nicht. Bleibt noch die Frage, ob das unter Win7 schon immer so war, oder ob das durch ein Update mal eingefügt wurde. Dann würde ich das Update nämlich gerne der IT zurückgeben ;-)
Diese Krankheit ist nicht auf Windows 7 beschränkt, das ist beim Explorer schon länger (immer?) so.
Vista hab ich nie benutzt. Und unter XP ist das doch meines Wissens nicht so. Das kann ich aber erst heute Abend mal ausprobieren.
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).
Moin, und wie das Windowsgebashe schon wieder los geht^^. Es ist einfach eine Designentscheidung gewesen und fällt unter die Rubrik "is halt so". Ich reg mich auch jedes mal innerlich auf, warum Dateinamen unter Linux Case sensitiv sind. Trage das aber nicht in jedes Forum (das hier ist echt Premiere). Welcher Depp benennt denn unterschiedliche Dateien mit gleichem Namen in underschiedlicher Groß- und Kleinschreibung? BTW, warum muss denn deine Datei unbedingt mit einem Punkt anfangen? Grüße,
Rufus Τ. Firefly schrieb: > Dateinamen dürfen nur dann mit einem Punkt anfangen, wenn sie einen > zweiten Punkt enthalten (und der darf nicht unmittelbar auf den ersten > folgen). Der Punkt ist der Separator zur sog. extension, die sich wiederum dadurch Kennzeichnet das Sie durch einen Punkt vom Rest des Namens getrennt wird. Das war's auch schon, alle andere kann man benennen wie man lustig ist, nur das z.B. ein .exe Aufruf vom Betriebssystem als Programmstart behandelt wird und andere extensions das zugeordnete Programm starten. Da immer der letzte Punkt im Namen die extension kennzeichnet macht ein Punkt am Anfang und sonst keiner aus dem Namen zwangsläufig eine extension. Rufus Τ. Firefly schrieb: > Offensichtlich sind die Organismen, die bei MS den Explorer entwickeln, > der Ansicht, ... Sie sind in erster Linie der Ansicht das nur Amateure den Explorer nutzen (zu recht meiner Meinung nach, ich hab das Ding nur im Notfall in Betrieb). Die Versuchen Sie aber von den größten Dummheiten abzuhalten, unter anderem von . .. ... Arien aus den oben genannten Gründen.
nicht "Gast" schrieb: > ?BTW, warum muss denn deine Datei unbedingt mit einem Punkt anfangen? m.W. war (ist?) es unter UNIX üblich, Dateien, deren Namen mit Punkt beginnt, standartmäßig nicht anzuzeigen (hidden). Viele Programme aus der UNIX-Welt, benennen ihre BAK-Dateien so. mfG ingo
... und viele Programme aus der Unix-Welt sind mehr schlecht als recht nach Windows portiert worden.
ingo schrieb: > m.W. war (ist?) es unter UNIX üblich, Dateien, deren Namen mit Punkt > beginnt, standartmäßig nicht anzuzeigen (hidden). Viele Programme aus > der UNIX-Welt, benennen ihre BAK-Dateien so. Was ja wenig relevant ist da Windows hidden files über Attribute regelt. Das ist genau so hirnlos wie die GroßKleinSchreibUng bei UNOX Systemen oder eben die extension mittels Punkt (da ja der Filetyp ein Attribut ist und auch dahin gehört). Das ganze hat sich mal in grauer Vorzeit unter CP/M einer ausgedacht und seitdem ist es eben so.
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: >> Es ist einfach eine Designentscheidung gewesen > Aber eine von Dos. Spatestens 2.0. Nicht CP/M`? > > 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. zSeries? > Und warum sollten betriebssystemübergreifende Programme die Dateien > unterschiedlich benennen müssen? Was ist denn ein betriebssystemübergreifendes Programm?
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.
Udo Schmitt schrieb: > Hirnlos sind eher Dinge wie Blanks in Dateinamen und Pfaden. Irgendwann war man bei Windows der Meinung das die alte 7 Bit Ascii 8.3 etc Konvention vielleicht nicht ganz ausreichend ist und das es noch andere Länder und Sprachen als USA/englisch gibt. Also hat man das ganze geöffnet, was kyrillisch, hebräisch Thai etc in Dateinamen ermöglicht und in diesen Ländern sehr hilfreich ist. Dabei gab es dann einen bösen bösen "Seiteneffekt", das -Ogott- Leerzeichen über das man sich anschließend wunderbar echauffieren konnte was die Leistung der Leute bei MS in keinster weise schmälert. Am Arial Unicode Font der einzieg Font der die fast die gesamte Welt abdeckt- haben übrigens 5 Leute mehrere Jahre gearbeitet und selbst dieses raffgierige Unternehmen aus Cupertino hatte ihn lizenziert während Microsoft ihn aller Welt zur freien Verfügung stellte. Der Slash und Backslash sind übrigens immer noch nicht im Dateinamen möglich. Schätze mal das ist bei UNOX nicht anders.
Bei mir geht übrigens im Explorer : ".OrdnerName." wird zu .OrdnerName Der Rächer der Transistormorde schrieb: > [...] > Sie sind in erster Linie der Ansicht das nur Amateure den Explorer > nutzen (zu recht meiner Meinung nach, ich hab das Ding nur im Notfall in > Betrieb). > [...] Wo würden denn die Vorteile darin liegen den Explorer nicht zu nutzen, navigieren kann man auch mit der Tastatur, an Dateiinformationen kommt man auch recht zügig, und es ist übersichtlicher sowie effektiver durch die Sortierungsmöglichkeiten.
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.
mr. mo schrieb: > Liegt wohl daran, dass Windoof denkt, dass es sich um eine Dateiendung > handeln könnte Es liegt wohl eher daran, daß Leute aus der Unox-Welt keine Ahnung von Dateiendungen haben und deshalb nicht begreifen können, daß es sowas in der Welt außerhalb von Unox geben könnte. Und hier will nun jemand partout nen Dateinamen kreieren, der nur aus Endung besteht. Ist nur Mutwillen ohne wirklichen Sinn dahinter. 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. W.S.
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.
Arc Net schrieb: > Dateinamen dürfen nur dann mit einem Punkt anfangen, wenn Das stimmt nicht. Z.B. Eclipse legt unter Windows in den Projekten Datein mit Namen an wie z.B. ".project". Und es gibt keine Probleme damit.
W.S. schrieb: > Es gibt hier übrigens auch > Laufwerksbuchstaben, anhand derer man verschiedene Speichervolumina > unterscheiden kann. Kennt man in der Unox-Welt auch bloß nicht. In der UNIX Welt verteilt der Admin dem Speicher. der DAU bracht sich da um nichts zu kümmern. In der UNIX Welt kann das halbe System auf der einen Platte liegen und die andere hälfte auf der anderen. Eine Festplatte mit einem Linux drauf kann man aus einen Computer raus ziehen und in den nächsten reinstecken und das System fährt hoch. Mach das mal mit einem Windows! Die Dateiverwaltung von Windows und UNIX sind zwei Paar Schuhe. Und technisch ist UNIX Windows immer um ein paar Jahre voraus.
Rene Schube schrieb: > Deshalb haben die jetzt auch zwei Möglichkeiten "FORMAT.COM" ist heute > eine URL und gleichzeitig ein ausführbares Programm. Nö. URLs beginnen stets mit einem scheme. (z.B. http: ftp: ...) Daß es Programme gibt (z.B. Browser), die in der Default-Konfiguration auch unvollständige Angaben (wie "FORMAT.COM") als URL interpretieren, ändert nix daran. siehe auch: http://de.wikipedia.org/wiki/Uniform_Resource_Locator http://FORMAT.COM wäre demnach ein URL. Gruß, Thosch
Win7 schrieb: > Bei mir geht übrigens im Explorer : ".OrdnerName." wird zu .OrdnerName Cool, das geht wirklich! Ist zwar auch total uneinsichtig, warum der Punkt am Ende verschwindet (wehe dem, der ein Punkt am Ende haben will!), aber es ist ein schneller Workaround in diesem Fall.
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
Klaus schrieb: > Cool, das geht wirklich! Ist zwar auch total uneinsichtig, warum der > Punkt am Ende verschwindet (wehe dem, der ein Punkt am Ende haben > will!), aber es ist ein schneller Workaround in diesem Fall. Das Thema ist schon etwas älter aber vielleicht interessiert es ja wen. Ich habe z.Zt. das Problem das make mir eine Datei mit einem "." am Ende erstellt. Diese wird im Windows-Ordner auch so angezeigt. Beim Versuch sie zu löschen kommt mir Windows damit dass die Datei gar nicht existiere !!!! Demnach kann sie auch nicht gelöscht werden (getestet unter Win7 / bzw. XP im Windows Virtual Mode unter Win7)
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.
Rene Schube schrieb: > Darin liegt ja der Murx von Windows. Der Type der Datei steht in der > Datei! > Sonst nix. Das ist wohl die dümmste Bemerkung im Thread - bei Windows weiss inzwischen auch der DAU dass eine .exe eine ausführbare Datei ist, bei Unix muss man die Datei erst öffnen, lesen und und in endlosen Listen magische Zahlen nachschlagen - und die Konsequenz ist dann, dass ein unix-typisches Programm Xyz zahllose Dateien des gleichen Namens Xyz in Unterverzeichnissen anlegt, z.B. Farben als /color/Xyz, Fonts als /font/Xyz usw. was eine Datensicherung ad absurdum führt, weil dann 20 Dateien gleichen Namens vorliegen mit völlig verschiedenem Inhalt. Natürlich kann man durch Umbenennen auch Schindluder treiben, die Versuche, durch verbotene Zeichen Dateien unkopierbar oder unlöschbar zu machen sind so alt wie Dateisysteme an sich. Verhindern lässt sich das nicht, irreguläre Dateinamen konnte man schon ganz einfach mit dem Norton Disk Explorer erzeugen. Gruss Reinhard
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.
A. K. schrieb: > Kenner fragen einfach das Programm > "file". Eine solche Krücke ändert doch nichts am dummen und ineffektiven Prinzip. Gruss Reinhard
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.
A. K. schrieb: > 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. viel Spass bei 1.000.000 dateien wo ein JPG versteckt ist und alles andere andere Formate sind. 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.
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.
Behämmert...warum muss man Dateinamen mit Punkt am Anfang verwenden? Völlig überlüssig...
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.
Rufus Τ. Firefly schrieb: > Dann wäre eigentlich ein sinnvoller Weg der, das Attribut in einen > Punkt zu übersetzen, und umgekehrt. Das ist im Netzwerk schlecht machbar, der Server weiss ja nicht ohne weiteres oder garnicht, wer zugreift. Ich sitze ja auch mal vor einem Windows-, mal vor einem Linux-Client, dazu kann man ja nicht den Server auf den Kopf stellen. Ich kann mich aber erinnern, dass ich schon in Windows Häkchen gesetzt habe bei der Option "Show .files" oder so ähnlich, damit kann man leben. Ich weiss bloss nicht mehr, ob das Original Microsoft war oder ein zugekaufter NFS-Client. Im übrigen sind die Konventionen von Dateisystemen dazu da dass man sich dran hält, und nicht dazu auszutesten wieweit man sie missbrauchen kann. Im Interesse einer friedlichen Existenz im Dschungel gemischter Systeme sollte man auch Spezialitäten einzelner Dateisystem vermeiden. Was als unvermeidbar übrigbleibt wie die 4GB-Begrenzung einiger Systeme ist schon schlimm genug. Gruss Reinhard
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.
Rufus Τ. Firefly schrieb: > Vom Server war auch keine Rede, das sollte der jeweilige Client > erledigen. Der kann aber auch nicht wissen, ob er nun auf ein Windows- oder auf ein Linux-Dateisystem zugreift. Ich will das auch garnicht wissen - mein Linux-Backup-Server hat gefälligst genauso auszusehen wie die Windows-Server. Und wozu soll NAS gut sein, wenn man sich um das verwendete Dateisystem Gedanken machen muss? Gruss Reinhard
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.
Rufus Τ. Firefly schrieb: > Das braucht man in Dateisystemen, die kein zusätzliches > "hidden"-Attribut haben. Ach Rufus, laß doch nicht die wichtigste Sibe aus. Ich schreib das mal so: "Das gebraucht man in Dateisystemen, die kein zusätzliches "hidden"-Attribut haben." Man braucht es nicht wirklich, sondern GEbraucht es lediglich. Man benötigt hidden weder bei Unix noch bei Windows. 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. Das Ansinnen von Klaus: Klaus schrieb: > Ich möchte habe hier eine eclipse Projekt-Datei, die ich in .project > umbenennen muss. ist also eher ein Mutwillen und ganz sicher nicht wirklich ein MUSS btw: gibt es bei Unix eigentlich noch andere stille Vereinbarungen dieser Art, also z.B. spezielle Textzeichen für readonly usw? W.S.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.