Diskussion:Versteckte Datei

Unter Linux (Ubuntu) eine Datei vor Windows (Windows Mobile) verstecken

Wie kann ich unter Linux (Ubuntu) eine Datei vor Windows verstecken? Am liebsten mit Hilfe des Dateimanagers Nautilus mit Rechtsklick auf die Datei. Helfen kann: mattrib; mtools (ferner Nautilus-Actions).

Ich sehe es als großes Problem bei Neuumsteigern von Windows auf Linux an, unter Linux das Datei-Attribut für Windows (Mobile) zu ändern. Besonders bei denen ist es ein Problem, die beides nebenher nutzen oder Windows Mobile auf dem Handy haben. Hier in Wikipedia sowie auf www.ubuntuusers.de wird wahrscheinlich als erstes geschaut, um dieses Problem zu lösen. --Patrick Mi 21:37, 10. Aug. 2011 (CEST)

Das ist nicht direkt ein Linux/Windows-Problem, sondern ein Problem der Dateisysteme. Unter Dos/Win besaßen und besitzen die Standard-Dateisysteme immer ein "Hidden" Flag. Das kann eine Software setzen, löschen oder ignorieren. (FAT, NTFS)

Linux ist weit weniger an ein bestimmtes Dateisystem gebunden; am weitesten verbreitet sind wohl ext2 und ext3. Diese besitzen kein solches Flag. Es ist üblich, dass Dateien, deren Name mit einem Punkt beginnt, als "versteckt" betrachtet werden, bzw. bei einer "normalen" Anfrage nicht gelistet werden sollen.

D.h. Du must deine Frage präzisieren:

1. In was für einem Dateisystem soll die Datei denn stecken? Es macht einen erheblichen Unterschied, ob die Datei in einem ext3 steckt, das Windows mittels Treiber "auch lesen & schreiben" kann (z.B. in einer Dual-Boot-Umgebung Ubuntu/Win7), oder ob die Datei in einem NTFS steckt, auf das Ubuntu mit Treibern zugreift.
2. Du musst die Umgebung genauer beschreiben. Ist das ein PC mit Dual-Boot-Installation? Oder ein Linux-Server, der Netzwerk-Freigaben für Windows-PCs mittels Samba anbietet? Oder eine Datei eines WebDAVs, auf das ein Linux- und ein Windows-Gerät zugreifen, oder eine Datei bei DropBox ?

Ohne weitere Infos ist keine Antwort möglich. --arilou (Diskussion) 17:08, 22. Apr. 2013 (CEST)

Malware, Viruse

Zur Notiz: Ein Abschnitt über systematisch durch Malware versteckte Dateien wurde herausgenommen --Itu 23:07, 27. Sep. 2011 (CEST)

Probleme

Die Ganze Problematik fehlt noch: man kann offenbar keine versteckten dateien mit mv verschieben, ausser einzeln und . und .. machen auch Probleme ,die sind aber gar nicht mal erwähnt obwohl sie da direkt dazugehören. --Itu (Diskussion) 06:39, 21. Apr. 2013 (CEST)

Nun, mit einem Datei-Browser kann man versteckte Dateien auch nicht verschieben, da nicht anklickbar (sind ja versteckt). Und es braucht zusätzliche Einstellungen oder Tasten(-Kombinationen), um das zu umgehen bzw. die Dateien angezeigt zu bekommen.

Kann aber in den Artikel, wenn gewünscht. --arilou (Diskussion) 17:16, 22. Apr. 2013 (CEST)

Fehlende Tiefe

Mir fehlen in dem Artikel grundlegende Informationen darüber, was die Eigenschaft "versteckt" denn nun bewirkt bzw. welche Aufgabe sie hat. Nicht für den Benutzer sichtbar? Sichtbar für alle Anwendungen, kann aufgerufen werden, kann geschrieben aber nicht gelesen werden? Ein Attribut zur Kennzeichnung von Berechtigungen oder nur von visueller Sichtbarkeit? Ist das Wort "sichtbar" in der Informatik metaphorisch gebraucht (= steht dem Anwender zur Verfügung?) Es fehlt (mir als Lexikonnutzer) eine Einführung über den Einsatz dieses Attributs, seinen Nutzen, wozu es allgemein dient, ob es erst mit grafischen Benutzeroberflächen eingeführt wurde oder schon vorher existierte. Insgesamt ist das noch kein Lexikonartikel, eher ein Magazinbeitrag, in dem gesammelt wurde, was man so als User weiß. Danke. (nicht signierter Beitrag von 188.104.128.242 (Diskussion) 08:00, 6. Mai 2020 (CEST))

Eine Fragestellung, die mit gerade einmal einem Halbsatz beantwortet werden kann, ist ganz sicher nicht "fehlende Tiefe" für den gesamten Artikel.

Unter MS-DOS gab es das 'hidden'-Flag schon lange Zeit vor den GUIs, soweit ich mich erinnere hatte es bei einem 'dir' aber keinen Effekt (und auch sonst so ziemlich keinen). Tatsächlich waren wohl erst "Endbenutzer"-GUI-Dateibrowser/-explorer die ersten Anwendungen, die 'hidden'-Dateien tatsächlich nicht anzeigten. Browser für Fachleute ignorieren es (zumindest als Voreinstellung) auch heute noch. (Genauso wie den Blödsinn "Dateinamenserweiterungen bei bekannten Typen ausblenden".)

--arilou (Diskussion) 09:18, 6. Mai 2020 (CEST)

Sicher? Waren nicht versteckte Dateien auch und gerade mit dem Aufruf von dir auch ausgeblendet?

Hier steht über den Zweck z.B. folgendes (auf Englisch leider): "The usual reason for hiding folders is because they are important to system or program operation and should not be deleted or moved in casual tidy-up operations."

Das würde ich auch so sehen. Auch in Unix sind "Dot Files" bei einem Aufruf von ls grundsätzlich versteckt. Wie bei dir kann man bei ls auch mit Optionen angeben, ob man versteckte Dateien nun sehen will oder nicht. Der Standard ist aber, dass versteckte Dateien versteckt bleiben, weil es ja sonst keinen Sinn machen würde, sie überhaupt zu verstecken.

‣Andreas•⚖ 10:57, 6. Mai 2020 (CEST)

Jedes Verzeichnis ist eine Datei

Bezüglich deiner Änderung:

• File Systems in Operating System – FILE DIRECTORIES: … The directory is itself a file, accessible by various file management routines.
• OS Directories … Directories are itself files in many systems.
• File Types – The UNIX filesystem contains several different types of files: ⬥ Ordinary Files … ⬦ Always located within/under a directory file, ⬥ Directories … ⬦ Never contain "real" information which you would work with (such as text). Basically, just used for organizing files.

Also, Verzeichnisse sind eine Datei – auf Dateisystemebene. So stand es auch da.

• PDF: Analysis of B-tree data structure and its usage in ... – so, ich es verstanden habe, hat sich das bei auf B-Tree-basierten Dateisystemen nicht verändert (im Speziellen Seite 4, 2.3.2 Filesystem)

Wenn man ein Verzeichnis wie eine Datei sieht, dann ist der einzige Unterschied, dass das Betriebsystem – genauer: das zuständige Dateisystem-Programm (Treiber) – für den Inhalt zuständig ist, da es sich um Datenstrukturen handelt, die weitere Dateien und Verzeichnisse enthalten können. Aus API-Sicht und Benutzer-Sicht muss es daher einen Unterschied geben, da man ein Verzeichnis nicht wie eine Datei öffnen kann, stattdessen gibt man dem Betriebssystem zu verstehen, wie es sich in dem Verzeichnisbaum bewegen soll, und das öffnet die „Dateien“=Verzeichnisse, um darin wie gewünscht zu navigieren.

Das ist zwar etwas holprig ausgedrückt, aber auf Ebene des Dateisystems sind Verzeichnisse eben Dateien. Daher können sie auch deren Attribute annehmen. Tatsächlich ist ja ein Attribut einer Datei, ob sie ein Verzeichnis ist oder nicht. Das lässt sich selbstverständlich nicht verändern, es ist bei der Erstellung vorgegeben. Aber alle anderen Attribute (Erstellungszeit, Zugriffszeit, Besitzer, versteckt etc.) sind auch auf Verzeichnisse anwendbar – weil es ja Dateien sind.

Habe ich das etwa falsch verstanden? Dann entschuldige ich mich...

Ansonsten: was passt mit meiner ursprünglichen Formulierung nicht?

‣Andreas•⚖ 15:17, 28. Mai 2020 (CEST)

P.S.: Danke für deine weiteren Verbesserungen! ‣Andreas•⚖ 15:22, 28. Mai 2020 (CEST)

zu Quelle 1: "The directory is itself a file, accessible by various file management routines." Nicht: "all", d.h. es ist eben nicht "ein File wie alle anderen", es sind (teilweise) spezielle Routinen nötig, oder manche File-behandelnde Routinen können Verzeichnisse nicht verarbeiten.

zu Quelle 2: "Directories are itself files in many systems" - warum nicht "in all systems" ? Na?

zu Quelle 3: "several different types of files: a) Ordinary Files [...] b) Directories" - hier muss also plötzlich der 'Fachbegriff' "ordinary file" eingeführt werden, weil Directories eben nicht dazu gehören.

Ich plädiere dafür, nicht kategorisch zu verfechten "Verzeichnis == Datei", sondern das offen zu lassen. Die Aussage ist im Artikel 'Versteckte Datei' sowieso unnötig.

--arilou (Diskussion) 15:34, 28. Mai 2020 (CEST)

Naja, gerade im weiteren Text gehe ich darauf ein, dass bei Unix "Everything is a file" jedes Verzeichnis eine Datei ist. Das ist verwirrender, wenn man nicht versteht, dass auf Dateisystemebene ein Verzeichnis wie eine Datei ist.

Was das Herumdrehen betrifft: Ja, habe ich ja geschrieben, dass es da Unterschiede beim Zugriff gibt, das ist API-Sache. Das Betriebssystem muss ja sicherstellen, dass man nicht mit z.B. Notepad eine Verzeichnis-Datei öffnet, diese leicht verändert abspeichert, und dann ein kaputtes Dateisystem hat.

Nochmal: Auf Dateisystem-Ebene soll heißen, wie Daten im Dateisystem gespeichert und verwaltet werden. Das ist bei Attributen ja auch so, und wird im Artikel beschrieben. Da geht es vielfach um das Low-Level-Dateisystem (data forks, resource forks, attributes...). Und ja, es geht auch darum, dass gerade Unix das genau umgekehrt macht: eine versteckte Datei ist dort eben eine reguläre Datei. Und weil ein Verzeichnis eine besondere Datei ist – ...auch ein reguläres Verzeichnis.

‣Andreas•⚖ 15:42, 28. Mai 2020 (CEST)

Der Artikel ist nicht auf Unix(-artiges) beschränkt, schon gar nicht in der Einleitung.

Ich hab' den Artikel jetzt nicht nochmal gelesen, aber wenn in einem Unix-spezifischen Abschnitt Aussagen stehen, die für wirklich alle Dateisysteme stimmen, die Unix-artige Systeme verwenden (können), dann ok - dort.

Afaik ist z.B. das Wurzelverzeichnis eines FAT-Dateisystems mitnichten ein 'normales File-Objekt', muss z.B. an ganz bestimmter Stelle gespeichert sein, mit limitierter Größe (soweit ich mich erinnere, dürfen max. 63 Dateien und/oder Unterverz. unter dem Rootverz. sein).

Das wär' schon mal 1 Gegenbeispiel.

--arilou (Diskussion) 17:11, 28. Mai 2020 (CEST)

Ja, das ist nur bei einem Flat Filesystem so, und bei beim Wurzelverzeichnis von FAT.

Bei allen anderen Verzeichnissen ist ein Verzeichnis eine Datei vom Typ "Verzeichnis". Hier steht es recht übersichtlich: File System Design – aus dieser Quelle:

• FAT: The superblock contains ... the root directory
• FAT: Directories are Files. Unlike the simple file structure from before, FAT has no directory block. Instead, directories are stored like files as an array of directory entries.

Der Spezialfall FAT ist also das Wurzelverzeichnis – und nur das.

• BSD: A UNIX FILE SYSTEM: Inode, or "Index node," is a block of fixed size that holds metadata about directory files or regular files.

Zusammenfassung: Wenn du auf einem Dateisystem, nur mal so als Beispiel, 100 Verzeichnisse hast, dann sind auf den meisten Dateisystemen diese 100 Verzeichnisse "Verzeichnis-Dateien", directory files, weil ein Dateisystem nun mal so organsisiert ist. Wenn diese Verzeichnisse nun allerdings auf einem FAT-Dateisystem sind, dann sind es nur 99 Verzechnisse, die als Datein abgespeichert sind...

Bei einem flachen Dateisystem (flat file system) gibt es keine Verzeichnisse. Die Informationen über die Dateien sind dann meist an vorgegebener Stelle – dem Superblock – gespeichert. Außer bei Inode-basierten Dateisystemen, oder bei B-Tree-basierten Dateisystemen, dann ist auch das eine Datei. Bei NTFS sind alle Dateien im MFT abgelegt – "reguläre" Dateien genauso wie "spezielle" Dateien, und auch Verzeichnisse. Der MFT selbst ist ebenfalls eine Datei.

Was ist also der Sonderfall, und was der Normalfall?!?

Aber okay, vielleicht sollte man die Information, dass ein Verzeichnis eine Datei ist, zur Beschreibung, wie das ganze auf UNIX ist, verschieben. Dann erschließt es sich dem Leser auch, und es ist zumindest – da sind wir uns ja einig – für UNIX richtig.

Also nochmal Danke für's überarbeiten.

‣Andreas•⚖ 09:34, 29. Mai 2020 (CEST)

Ich habe diese (private) Diskussion zur Archivierung hierher verschoben. ‣Andreas•⚖ 23:43, 9. Jul. 2020 (CEST)