*LOL*

sorry, aber das titantic-erlebnis wollte ich dir nicht ersparen...

...denn nicht umsonst hab ich dir unix/linux-lösungen empfohlen

das, was du unter windows als dateiattribut kennst, gibt es in dem sinne nicht unter unix/linux...

hier gibt es nur (grob gesagt) drei zustände: lesen, schreiben, ausführen und diese drei gelten wiederum für 3 abteilungen: besitzer, gruppe und andere

wenn du mit ls -l ein inhaltsverzeichnis anssiehst, dann siehst du z.b. folgende zeilen...

</font><blockquote>Code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">drwxr-xr-x 3 root root 153 2002-11-08 16:49 fah</pre>[/QUOTE]in diesem falle steht d für ein verzeichnis (es kann auch anderes sein, mehr dazu in deinen handbüchern), die ersten dreimal rwx sthene für lesen-schreiben-ausführen (read-write-execute), dieser wert steht für den besitzer der datei/des verzeichnisses. das zweite dreierpack r-x heisst, das nur read und execute erlaubt ist, und betrifft die gruppe. der dritte dreierpack hat in diesem falle die gleiche bedeutung wie bei der gruppe, steht aber für andere (und zwar alle anderen, die nicht besitzer und nicht in der gruppe sind )

das ganze ist eine richtige zugriffsverwaltung, die natürlich nur mit einem entsprechenden dateisystem funktioniert [und mit fat/fat32 funktioniert das nicht, daher hat ja auch m$ ein geeignetes für nt/2000/xp (weiter)entwickelt: ntfs]. das heisst aber jetzt nicht, das es mit ntfs 1:1 funktioniert.

als einzige ausnahme sind image-programme, wie sie im link im ersten betrag genannt werden, da sie sectorweise die partition auslesen...

sorry, ich hätte 20x hinweisen können, du hättest mir nicht geglaubt...

erst durch die eigene bruchlandung bist jetzt hoffentlich geheilt

tipp am rande: du hast mit suse gute handbücher mitbekommen, lies diese auch...

zeitknappheit oder gar gier sind zwar gründe, aber keine entschuldigung - gerade bei den grundlagen sollte man nicht schlampen, denn darauf baut das weitere wissen auf...

genug der predigt - die strafe hast dir eh selbst auferlegt...

[img]graemlins/teufel3.gif[/img]

Ja, bestimmte Erlebnisse muss man wohl gelegentlich haben

Erfahrungen durch Learning by doing [ohne Handbuchwissen zu
vernachlässigen] haben aber den Vorteil, dass sich allmählich ein
dauerhaftes Wissen einstellt - sonst würde man bald zu den
Häschen zählen, die bei jeder Kleinigkeit die merkwürdigsten
Fragen stellen.

Im Ernst, mein Zieltermin für Linux ist Weihnachten (2002), so dass
noch weitere Hautabschürfungen eingeplant sind: Beide Drucker
laufen, Internet funktioniert, Briefe kann ich schreiben, Daten-
sicherung ist das aktuelle Thema, dann CD-Brennen unter Linux,
sieht nicht schlecht aus..

Wenn es denn zur Erheiterung beigetragen hat bzw. anderen zeigt,
dass Einstiegsprobleme normal sind und wie man sie Stück für
Stück angeht, ist das mehr, als ich erwarten konnte.. [img]graemlins/heilig.gif[/img]

[ 14. November 2002, 22:05: Beitrag editiert von: SilverSurfer99 ]

Hier bin ich wieder - mit neuen Erfahrungen.

</font><blockquote>Zitat:</font><hr />n_dot_force schrieb: runlevel 1 ist der single-user-mode, das heisst,
dass alle netzwerk- und multi-user-dienste abgeschaltet werden. bei unix/linux
gibt es keine unmengen an dateien - dateien, die gerade genutzt werden, werden
sowieso nur im /temp-verzeichnis geöffnet, und im runlevel 1 (da ja rein auf
shellebene) steigt die zahl dieser temp-dateien gen nul - daten und programme
sind immer für zugriffe verfügbar!</font>[/QUOTE]Da mein PC vielleicht mal wieder was Besonderes sein will, habe ich nach einer
Überprüfungsmöglichkeit gesucht. Falls jemand nachstehendes Überprüfverfahren
umständlich findet - ich musste mit meinen Kenntnissen auskommen.
---
Bei der letzten Suse8.1-Neuinstallation bin ich die Standardpaket-Unterpositionen
einzeln durchgegangen und habe dabei das Tool lsof (list open files) entdeckt und
zusätzlich angeklickt. Hier der Test auf offene (evtl. nicht sicherbare) Dateien:
Als root anmelden - init 1 - lsof - und oh Schreck, drei volle Bildschirmseiten!
Also Wiederholung mit lsof|more und alle /NAME's notiert, bei denen unter SIZE
Bytesgrößen angegeben sind. Nach Eliminierung mehrfach angezeigter NAME's
blieben 12 Datei-/Anwendungsnamen übrig:

432.264 /sbin/init
477.132 /bin/bash
084.688 /lib/ld-2.2.5.so
649.639 /lib/libreadline.so.4.3
122.891 /lib/libhistory.so.4.3
307.598 /lib/libncurses.so.5.2
011.832 /lib/libdl.so.2
050.549 /lib/libnss_compat.so.2
087.569 /lib/libnsl.so.1
096.488 /usr/lsof
023.704 /bin/more
1.312.470 /lib/libc.so.6
12 Datei(en) 3.656.824 Bytes

Abschlusstest: Wenn die 12 Dateien sicherbar sein sollten, müssen sie also auch
kopierbar sein. Daher 12mal 'CP /NAME's /test.dat - dir /test.dat' und Vergleichen
der Bytesgrößen /NAME's mit /test.dat
Ergebnis: 12mal Übereinstimmung der Größen, dh. Sicherungsmöglichkeit ist damit
offenbar aussichtsreich. Sieht jemand noch eine Lücke/Schwäche im Testvorgehen?
Inzwischen habe ich den Kopiertest auch auf eine VFAT-Partition wiederholt -
gleiches positives Ergebnis.

Der endgültige Nachweis ist allerdings erst erbracht durch Packen mit RARLinux,
Entpacken auf ein freies Laufwerk und bytesweise genauer Dateienvergleich.
Warum ich soviel Anfangszeit auf das Thema Datensicherung 'verschwende?'
Nun, das ist ein Eckpfeiler der Security - irgendwann würde die schöne Arbeit
an Linux sonst im Datencrash begraben werden. Und Linux scheint für mich der
Beginn einer langen Freundschaft zu werden.

Stilecht geschrieben mit kwrite und abgesandt mit Mozialla 1.01.

[ 18. November 2002, 23:13: Beitrag editiert von: SilverSurfer99 ]