Nicht, dass ich wüsste. Wenn ich den Unix-FHS (filesystem hierarchie standard) richtig in Erinnerung habe, ist /tmp nur für temporäre Daten innerhalb der Laufzeit zu nutzen, was schlicht bedeutet, es wird nicht sichergestellt, dass die Daten einen Systemneustart überleben. Es muss also nicht gelöscht werden, aber es kann und wird auch mitunter. Und man sollte als Nutzer im Zweifel davon ausgehen, dass /tmp gelöscht werden kann, wenn man nicht alleine an der Maschine arbeitet und sie neu gestartet werden musste. Und bei solaris wie auch einigen Linuxen z.B. ist das gar systemtechnisch garantiert, dass ein reboot das /tmp löscht, es ist dort als ramdisk eingerichtet Für längerfristige temporäre Daten gibt es /var/tmp.
Ist jedenfalls bei unserer Backup-Truppe immer ein grosses Gelächter, wenn sie Anfragen einiger unbedarfter Nutzer bekommen "bitte stellt das und das in /tmp wieder her, hat irgend wer gelöscht!!". So eine Anfrage ist bei Unix-Systemen so lustig wie unter Windows "ich hab das Internet gelöscht!!"
Kann ich auch nicht bestätigen. Ich hab noch mal meine alten Schulungsunterlagen hervorgekramt, und da steht definitiv, es wird empfohlen, von Zwang ist nichts zu merken. Wer also sein /tmp für die Ewigkeit speichern will, kann es ruhig. Er darf nur nicht Zeter und Mordio schimpfen, wenn auf anderen Maschinen, anderen Distributionen, oder überhaupt irgend etwas "unixigem", das /tmp eine Verfallszeit hat
Von Neuer_ohne_Login am Fr, 1. April 2011 um 00:58 #
Hallo Du,
ich glaube RHEL löscht dort Sachen, die beim Boot eine atime von >14 Tagen haben, also solange nicht darauf zugegriffen wurde. Alles was jünger ist oder zuletzt verwendet wurde, überlebt den reboot.
Eine vernünftige Regelung wie ich finde.
Die Sache mit /tmp ist allerdings, dass Du davon ausgehen musst, dass es nur bis zu einem Reboot lebt, selbst wenn es bisweilen anders sein könnte.
Bin kein Experte dahingehend aber warum kommt das nicht einfach nach Temp? Schließlich sind es ja nur temporäre Programmdateien. Oder liegt es daran, dass /tmp unter Umständen auch auf anderen Parttionen liegen könnte, da bspw. für Bild-/Videoverarbeitung ne Menge temporärer Speicher notwendig sein kann.
/tmp/run hätte wohl die gleichen Probleme wie /var/run. Außerdem kann /tmp von normalen Benutzern vollgeschrieben werden. Ob absichtlich oder unabsichtlich, das könnte dann Fehler in Systemprogrammen nach sich ziehen.
hjb hat ja auch nichts gegenteiliges behauptet. Er hat nur geschrieben, daß /tmp von Benutzern VOLLgeschrieben werden kannn. Und diese Möglichkeit besteht durchaus.
Korrekt. Tmp liegt normal auf einer eigenen Partition, WEIL User diese bis oben befüllen können. Und zwar ALLE. Und wenn run voll ist, bzw gefüllt werden könnte, so kannst du dir vorstellen was alles nicht mehr geht.
Lock und Run Infos haben in einem WorldWritable Partition/Directory nix verloren.
Der FHS in genannter Version ist erstens nicht auf immer und ewig in Stein gemeißelt, sondern nur ein Abbild dessen, was ohnehin schon Usus ist. Zweitens räumt er Distributoren explizit die Möglichkeit ein, im Root-Verzeichnis neue Verzeichnisse einzuführen, wenn sie diese Lösung entsprechend ausgiebig und besonnen diskutiert haben. Das scheint bei /run stattgefunden haben, da gleiche mehrere Distributoren an der Diskussion beteiligt waren.
Nein, sie muss nicht in Stein gemeisselt bleiben. Aber macht nur zu. zurück zum Chaos, und weg mit Standards. Auch wenn sich Linux gerne als "Linux is not an UNIX", so werden sie damit wieder einmal ein Schritt inkompatibler zum Rest der UNIX-Welt.
Wo ist dein Problem du Wahnsinniger? Hast du die Fedora-Maling-Liste abonniert? Nein? Was gibt dir dann das Recht hier den Mund aufzumachen in dieser Form?
FHS ist prinzipiell gut ABER 7 Jahre alt! /run wurde mit allen relevanten Distributionen ausdiskutiert systemd ist sicher noch nicht perfekt, aber es wird die Zukunft sein
Soll man also jetzt noch 5 Jahre warten bis die FHS mal wieder ein Update bekommt und in der Zwischenzeit implementiert jede Duistribution weiter krude Workarounds die man dann irgendwann aufräumen darf?
Es stimmt natürlich, der Name selbst ist eigentlich vollkommen irrelevant, es könnte genausogut /stop oder /lunch heißen. Entscheident ist, dass es eindeutig, eingängig und vor allem eben auf einer günstigen Position liegt, also nicht unterhalb eines möglicherweise erst spät (oder bei Fehlern gar nicht) eingehangenen Mountpoints wie /var/run oder /tmp/run.
a) Sinn und b) ist er bereits in Fedora15 Rawhide drin (siehe: http://koji.fedoraproject.org/koji/buildinfo?buildID=235846 ) und das nicht erst seit heute.
> Der über sechs Jahre nicht aktualisierte FHS soll außerdem angepasst werden. Dies warf am Rande der Diskussion die Frage auf, wie relevant FHS und die Linux Standard Base noch sind und ob nicht aktuelle Distributionen wie Fedora den Standard definieren.
Ich finde, LSB ist in der Theorie gut, aber (auf Grund von Fehlern der Distributoren) weitestgehend wertlos.
Beispiel distributionsabhängige Init-Skripte - dank LSB theoretisch machbar. Praxis: Laut http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/initsrcinstrm.html lässt sich ein Init-Skript z. B. mit "/usr/lib/lsb/install_initd /etc/init.d/example.com-coffeed" auf allen LSB-konformen Distributionen installieren. In der Praxis benötigt der beschriebene Befehl unter Fedora 14 noch einen Parameter "--add" um zu funktionieren und unter Debian funktioniert es eben nicht mehr, wenn mann noch ein "--add" reinmogelt.
Dass man erst LSB-Kompatiblitätspakete nachinstallieren muss ist noch ein anderes Thema...
Leider ist die Init-Script Sektion in der LSB alles andere als durchdacht oder sie ist einfach veraltet.
Ein weiteres Beispiel dafür sind die log_*_msg Funktionen die von der LSB definiert werden. Der in so ziemlich jeder Distribution übliche Weg einen Daemon zu starten ist folgender:
1) Meldung welcher Daemon gestartet wird. 2) Daemon starten. 3) Meldung ob der Start erfolgreich war oder nicht.
Aber genau dass lässt sich mit den log_*_msg Funktionen der LSB nicht abdecken, da diese Schritt 1 und Schritt 3 untrennbar zusammenfassen.
Nicht umsonst werden die LSB-Funktionen von den Distributionen auch nicht genutzt. Wer ein Initscript nur unter Nutzung der LSB-Funktionen schreiben möchte, ist leider auf verlorenem Posten.
In Linux home directories liegen neben wichtigen persönlichen Daten und Konfigurations-Dateien auch viel zeugs wie z.B. cache Dateien von Web-Browsern oder etwa googleearth. Und viele Systemkonfigurationssachen, etwa von KDE oder Gnome.
Bei einem Backup kann man diese Daten nur schwer ausschliessen da sie ja direkt im home folder liegen. Da ich ein tägliches incremental backup mache ist das ärgerlich. Eigentlich gehören die Daten vielleicht eher nach /tmp, aber beim booten sollen sie ja nicht gelöscht werden. Der user bräuchte ein persistentes Systemverzeichnis in dem alle ~/.* files und directories verschwinden. Vielleicht so was wie /cache/user/
Und noch ein Vorteil. Das Home-Verzeichnis könnte jetzt auf einem externen Raid-Server liegen und man könnte sich trotzdem einloggen auch wenn der Server (noch) nicht verfügbar ist. (Ich starte meinen per WOL wenn der client hochfährt und das dauert ein paar sekunden länger).
Frag mich manchmal ob ich der einzige bin der so was macht?
Nicht wirklich :) Der überwiegende Teil der Linux User, mich eingeschlossen, macht viel komisches Zeug mit seinen Kisten.
Ich spiegle das Debian Archiv komplett und auch nochmal in teiene. Zusätzlich spiegle ich gerade das Archiv von kernel.org Speicherplatz ist mir 9 TB + ~2 TB Reserve auch genug da. Genutzt wird davon effektiv rund 6-7 also nicht gerade wenig.
Von Kenner der Szene am Do, 31. März 2011 um 15:02 #
Das stimmt! Da muss man Windows _ausnahmsweise_ mal loben. Benutzerbezogene Anwendungsdaten kommen in das Verzeichnis \User\ \App Data\*
Dieses Verzeichnis kann man wunderbar excluden.
Wünsche mir seit Jahren auch so ein Verzeichnis unter Unix-Like-Systemen.
Sowas wie: /home/ /.application-data/*
Ich glaub als Unix damals entworfen wurde, hatte man noch nicht daran gedacht, dass es zig tausende Programme gibt auf einem System die alle das Home-Verzeichnis vollbomben.
Scheinbar beschätigt ihr euch nicht wirklich mit Linux, den ansonsten würdet wissen, dass dieses Verzeichnis schon seit geraumer Zeit existiert:
~/.config
Für Cache-Dateien gibt es das Verzeichnis "~/.cache".
Leider benutzen nicht sehr viele Programme diese beiden Verzeichnisse, aber die Anzahl derjenigen, die sie benutzen, wächst stetig. So legt z.B. Chrome/Chromium alle Konfigurationsdateien und Addons unter ".config" ab, der Cache wandert nach ".cache".
Ein Teil von GNOME ist z.B. schon umgestellt (Evolution benutzt beide Verzeichnisse), KDE benutzt es seit Version 4 (soviel ich weiß), viele andere Programme ebenfalls.
Es ist also nicht ein Problem des Systems, sondern der Programme bzw. der Entwickler. Diese müssten ihre Programme nur umstellen.
Ich glaub als Unix damals entworfen wurde, hatte man noch nicht daran gedacht, dass es zig tausende Programme gibt auf einem System die alle das Home-Verzeichnis vollbomben. :(
Dafür ist das Home-Verzeichnis aber da. Alle Benutzerdaten sollen darin liegen. Es ist das einzige Verzeichnis, in welchem der normale Benutzer normalerweise Schreibrechte hat. Anderswo hat er gefälligst nicht rumzupfuschen.
Von Kenner der Szene am Do, 31. März 2011 um 15:29 #
Okay, die Verzeichnisse kenne ich in der Tat nicht. Freut mich das sowas eingeführt wurde.
Zu meiner Aussage, zur Konzeption: Es ist klar, das der Benutzer in seinem Home-Verzeichnis Schreibrechte hat um seine Daten abzulegen. Darunter stelle ich aber Dokumente, Bilder, Filme, usw. und nicht auf der selben Ebene dutzende bis tausende von Anwendungsordnern wo Anwendungen ihre Konfig-Daten sichern.
Wo sollen denn die Anwendungprogramme dann ihre Daten hinschreiben?
Unter Windows landen diese doch ebenfalls im passenden Benutzerverzeichnis, nur dort halt in einem Unterverzeichnis. Konzeptionell ändert sich aber nichts.
Naja, wo sollten Anwendungen ihre Config-Daten denn sonst speichern? Sowas gehoert ins Home. Wenn ich mein Home von nem anderen System mounte, dann will ich natuerlich auch dort meine anwendungsbezogenen Einstellungen haben. Ein Verzeichnis unabhaengig vom Home ist also Bloedsinn. Sowas unter .config und .cache abzulegen, also eine Ebene tiefer als das reine Home-Verzeichnis, macht aber schon Sinn. Denn meine Config will ich schon sichern, der Cache ist mir da aber nicht so wichtig
Ob diese Verzeichnisse verwendet werden ist glaub ich nicht mal so eine Frage der Anwendung, sondern des Frameworks. Soweit ich mich erinnern kann werden z.B. bei Qt-Programmen, die die entsprechenden Klassen des Frameworks fuer ihre Config verwenden, diese Daten eben unter .config gespeichert. Vielleicht muessten in erster Linie mal die Frameworks umgestellt werden...
Scheinbar beschätigt ihr euch nicht wirklich mit Linux, den ansonsten würdet wissen, dass dieses Verzeichnis schon seit geraumer Zeit existiert: ~/.config Für Cache-Dateien gibt es das Verzeichnis "~/.cache".
Und für Programmdaten ~/.local/share
Alles Defaultwerte, überschreibbar mittels Umgebungsvariablen $XDG_CONFIG_HOME, $XDG_CACHE_HOME und $XDG_DATA_HOME
Siehe dazu auch http://standards.freedesktop.org/basedir-spec/latest/
Wenn du den Cache der User in /cache/$user haben willst, könntest du $XDG_CACHE_HOME in den Loginscripts oder über PAM eben auf diesen Wert setzen.
Wenn die Variable nicht gesetzt oder leer ist (was praktisch meistens der Fall ist), dann gehen Programme von $HOME/.cache aus. D.h. alternativ kann man natürlich einen Symlink von /cache/user nach $HOME/.cache setzen.
Anstatt endlich mit der Schweinerei im Linux Filesystem endlich aufzuräumen - Siehe (fast) Android, wird jetzt noch mehr davon erzeugt! Wieso müssen immer die Akademiker mit ihren, im Elfenbeinturm ersonnen, Spinnereien bei Linux den Ton angeben? Wie wärs zur Abwechslung mal wieder mit etwas Praxisbezug? Wieso wird immer gepachworkd? Zuerst die spinnerei mit isapnp (war schon vor Längerem), dann devfs, udev, hal, PolicyKit, sysfs, etc.). All diese Hacks versuchen nur Probleme zu lösen die in der grundlegenden Architektur von Linux/Unix begründet liegen. Als die Unix Standards gemacht wurden, hat eben niemand an usb, Webcams, DVD's, hotplug oä. gedacht. Das heisst das grundlegende Problem einer sauberen Hardware-Integration (und in diesem Fall, eines sauberen Boot-Prozederes) besteht noch immer, es werden lediglich Symptome bekämpft. Wenn Linux schon nicht Unix ist, muss darauf auch nicht mehr Rücksicht genommen werden. Wie wäre es mal mit einem wirklich SAUBEREN Design und Implementierungs Refresh, welcher den Staub der letzten 20 Jahre wegwischt und das System in die Gegenwart bringt?
> Wieso müssen immer die Akademiker mit ihren, im Elfenbeinturm ersonnen
Spinnst du?
Diese Änderung wurde NICHT im Elfenbeinturm ersonnen sondern ist eine pragmatische Lösung, wäre sie im Elefenbeinturm ersonnen würde es noch 10 Jahre dauern bis sie beim Enduser ankommt
warum nicht /tmp/run genommen wird ?
Die alten Laufzeitdaten sind doch sowieso nach einem Reboot gelöscht. Genauso ist es doch mit dem Inhalt des /tmp Verzeichnisses.
Die Wurzel des Verzeichnisbaums aufzublähen, findet meinen Geschmack nicht.
Ist es eigentlich definiert, dass /tmp/ nach dem Mounten bei Systemstart leer ist?
Nö, muss nicht sein.
Nicht, dass ich wüsste. Wenn ich den Unix-FHS (filesystem hierarchie standard) richtig in Erinnerung habe, ist /tmp nur für temporäre Daten innerhalb der Laufzeit zu nutzen, was schlicht bedeutet, es wird nicht sichergestellt, dass die Daten einen Systemneustart überleben. Es muss also nicht gelöscht werden, aber es kann und wird auch mitunter. Und man sollte als Nutzer im Zweifel davon ausgehen, dass /tmp gelöscht werden kann, wenn man nicht alleine an der Maschine arbeitet und sie neu gestartet werden musste. Und bei solaris wie auch einigen Linuxen z.B. ist das gar systemtechnisch garantiert, dass ein reboot das /tmp löscht, es ist dort als ramdisk eingerichtet
Für längerfristige temporäre Daten gibt es /var/tmp.
Ist jedenfalls bei unserer Backup-Truppe immer ein grosses Gelächter, wenn sie Anfragen einiger unbedarfter Nutzer bekommen "bitte stellt das und das in /tmp wieder her, hat irgend wer gelöscht!!". So eine Anfrage ist bei Unix-Systemen so lustig wie unter Windows "ich hab das Internet gelöscht!!"
Ja, die Definition sieht vor das /tmp beim Reboot gelöscht wird, /var/tmp aber nicht.
MfG =HAL-9000=
Welche Definition sieht das Löschen vor?
Die FHS (2.3) empfiehlt das Löschen von /tmp; aber verpflichtend ist es nicht!
http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES
Kann ich auch nicht bestätigen. Ich hab noch mal meine alten Schulungsunterlagen hervorgekramt, und da steht definitiv, es wird empfohlen, von Zwang ist nichts zu merken. Wer also sein /tmp für die Ewigkeit speichern will, kann es ruhig. Er darf nur nicht Zeter und Mordio schimpfen, wenn auf anderen Maschinen, anderen Distributionen, oder überhaupt irgend etwas "unixigem", das /tmp eine Verfallszeit hat
Hallo Du,
ich glaube RHEL löscht dort Sachen, die beim Boot eine atime von >14 Tagen haben, also solange nicht darauf zugegriffen wurde. Alles was jünger ist oder zuletzt verwendet wurde, überlebt den reboot.
Eine vernünftige Regelung wie ich finde.
Die Sache mit /tmp ist allerdings, dass Du davon ausgehen musst, dass es nur bis zu einem Reboot lebt, selbst wenn es bisweilen anders sein könnte.
Gruss,
Kay
Weil dann genau das gleiche Problem besteht, von dem man eigentlich weg möchte.
es geht auch um vorgänge beim bootvorgang.
/var/run wurde von einigen distributionen zB schon vor /var gemountet als tmpfs. andere nutzten /dev/.dotfiles was auch nicht im sinne des ganzen ist.
/tmp/run wäre noch unlogischer als /var/run und das problem würde bestehen bleiben.
> warum nicht /tmp/run genommen wird ?
Was soll das bringen?
Steht /tmp BEIM BOOT garantiert zur Verfügung?
Nein?
Siehst und, genau das gleiche problem wie /var/
Bin kein Experte dahingehend aber warum kommt das nicht einfach nach Temp? Schließlich sind es ja nur temporäre Programmdateien.
Oder liegt es daran, dass /tmp unter Umständen auch auf anderen Parttionen liegen könnte, da bspw. für Bild-/Videoverarbeitung ne Menge temporärer Speicher notwendig sein kann.
/tmp/run hätte wohl die gleichen Probleme wie /var/run. Außerdem kann /tmp von normalen Benutzern vollgeschrieben werden. Ob absichtlich oder unabsichtlich, das könnte dann Fehler in Systemprogrammen nach sich ziehen.
In /tmp kann kein Benutzer die Dateien eines anderen Benutzers überschreiben. Jedenfalls nicht wenn die Dateisystem-Rechte korrekt gesetzt sind (o+t)
hjb hat ja auch nichts gegenteiliges behauptet. Er hat nur geschrieben, daß /tmp von Benutzern VOLLgeschrieben werden kannn. Und diese Möglichkeit besteht durchaus.
Korrekt. Tmp liegt normal auf einer eigenen Partition, WEIL User diese bis oben befüllen können. Und zwar ALLE.
Und wenn run voll ist, bzw gefüllt werden könnte, so kannst du dir vorstellen was alles nicht mehr geht.
Lock und Run Infos haben in einem WorldWritable Partition/Directory nix verloren.
Ist die ganze Diskussion nicht etwas überflüssig?
Ob das Verzeichnis jetzt "/var/run", "/run" oder auch "/Schnitzel_mit_Pommes" heißt, ist doch wirklich irrelevant.
Nein, ist es nicht! Es gibt schliesslich einen Standard der das regelt, und aus gutem Grund so eingeführt wurde.
http://www.pathname.com/fhs/pub/fhs-2.3.html
http://de.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
Erwartest du das z.B. ein Softwareentwickler auf dein /Schnitzel_und_Pommes Rücksicht nimmt? Kannste aber vergessen.
Der FHS in genannter Version ist erstens nicht auf immer und ewig in Stein gemeißelt, sondern nur ein Abbild dessen, was ohnehin schon Usus ist. Zweitens räumt er Distributoren explizit die Möglichkeit ein, im Root-Verzeichnis neue Verzeichnisse einzuführen, wenn sie diese Lösung entsprechend ausgiebig und besonnen diskutiert haben. Das scheint bei /run stattgefunden haben, da gleiche mehrere Distributoren an der Diskussion beteiligt waren.
Nein, sie muss nicht in Stein gemeisselt bleiben. Aber macht nur zu. zurück zum Chaos, und weg mit Standards. Auch wenn sich Linux gerne als "Linux is not an UNIX", so werden sie damit wieder einmal ein Schritt inkompatibler zum Rest der UNIX-Welt.
Ausgiebig und besonnen diskutiert! Lachhaft.
> Ausgiebig und besonnen diskutiert! Lachhaft
Wo ist dein Problem du Wahnsinniger?
Hast du die Fedora-Maling-Liste abonniert?
Nein?
Was gibt dir dann das Recht hier den Mund aufzumachen in dieser Form?
FHS ist prinzipiell gut ABER 7 Jahre alt!
/run wurde mit allen relevanten Distributionen ausdiskutiert
systemd ist sicher noch nicht perfekt, aber es wird die Zukunft sein
Soll man also jetzt noch 5 Jahre warten bis die FHS mal wieder ein Update bekommt und in der Zwischenzeit implementiert jede Duistribution weiter krude Workarounds die man dann irgendwann aufräumen darf?
Selten so einen Blödsinn wie von dir gelesen!
Es stimmt natürlich, der Name selbst ist eigentlich vollkommen irrelevant, es könnte genausogut /stop oder /lunch heißen. Entscheident ist, dass es eindeutig, eingängig und vor allem eben auf einer günstigen Position liegt, also nicht unterhalb eines möglicherweise erst spät (oder bei Fehlern gar nicht) eingehangenen Mountpoints wie /var/run oder /tmp/run.
habe ich eigentlich erst morgen erwartet.
Eher nicht, weil dieser Change macht
a) Sinn
und
b) ist er bereits in Fedora15 Rawhide drin (siehe: http://koji.fedoraproject.org/koji/buildinfo?buildID=235846 ) und das nicht erst seit heute.
> Der über sechs Jahre nicht aktualisierte FHS soll außerdem angepasst werden. Dies warf am Rande der Diskussion die Frage auf, wie relevant FHS und die Linux Standard Base noch sind und ob nicht aktuelle Distributionen wie Fedora den Standard definieren.
Ich finde, LSB ist in der Theorie gut, aber (auf Grund von Fehlern der Distributoren) weitestgehend wertlos.
Beispiel distributionsabhängige Init-Skripte - dank LSB theoretisch machbar. Praxis: Laut http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/initsrcinstrm.html lässt sich ein Init-Skript z. B. mit "/usr/lib/lsb/install_initd /etc/init.d/example.com-coffeed" auf allen LSB-konformen Distributionen installieren. In der Praxis benötigt der beschriebene Befehl unter Fedora 14 noch einen Parameter "--add" um zu funktionieren und unter Debian funktioniert es eben nicht mehr, wenn mann noch ein "--add" reinmogelt.
Dass man erst LSB-Kompatiblitätspakete nachinstallieren muss ist noch ein anderes Thema...
Leider ist die Init-Script Sektion in der LSB alles andere als durchdacht oder sie ist einfach veraltet.
Ein weiteres Beispiel dafür sind die log_*_msg Funktionen die von der LSB definiert werden. Der in so ziemlich jeder Distribution übliche Weg einen Daemon zu starten ist folgender:
1) Meldung welcher Daemon gestartet wird.
2) Daemon starten.
3) Meldung ob der Start erfolgreich war oder nicht.
Aber genau dass lässt sich mit den log_*_msg Funktionen der LSB nicht abdecken, da diese Schritt 1 und Schritt 3 untrennbar zusammenfassen.
Nicht umsonst werden die LSB-Funktionen von den Distributionen auch nicht genutzt. Wer ein Initscript nur unter Nutzung der LSB-Funktionen schreiben möchte, ist leider auf verlorenem Posten.
In Linux home directories liegen neben wichtigen persönlichen Daten und Konfigurations-Dateien auch viel zeugs wie z.B. cache Dateien von Web-Browsern oder etwa googleearth. Und viele Systemkonfigurationssachen, etwa von KDE oder Gnome.
Bei einem Backup kann man diese Daten nur schwer ausschliessen da sie ja direkt im home folder liegen. Da ich ein tägliches incremental backup mache ist das ärgerlich. Eigentlich gehören die Daten vielleicht eher nach /tmp, aber beim booten sollen sie ja nicht gelöscht werden. Der user bräuchte ein persistentes Systemverzeichnis in dem alle ~/.* files und directories verschwinden. Vielleicht so was wie
/cache/user/
Und noch ein Vorteil. Das Home-Verzeichnis könnte jetzt auf einem externen Raid-Server liegen und man könnte sich trotzdem einloggen auch wenn der Server (noch) nicht verfügbar ist. (Ich starte meinen per WOL wenn der client hochfährt und das dauert ein paar sekunden länger).
Frag mich manchmal ob ich der einzige bin der so was macht?
Viele Grüße,
Wilhelm
Nicht wirklich :)
Der überwiegende Teil der Linux User, mich eingeschlossen, macht viel komisches Zeug mit seinen Kisten.
Ich spiegle das Debian Archiv komplett und auch nochmal in teiene.
Zusätzlich spiegle ich gerade das Archiv von kernel.org
Speicherplatz ist mir 9 TB + ~2 TB Reserve auch genug da.
Genutzt wird davon effektiv rund 6-7 also nicht gerade wenig.
Dass sagt wohl alles
T-Virus
Bei einem Backup kann man diese Daten nur schwer ausschliessen da sie ja direkt im home folder liegen.
find ~ -maxdepth 1 ! -iname ".*"
Und das knallst in tar, dar, oder wo auch immer rein. Ich seh da kein Problem...
Ich finde deine Idee (sry...) bescheuert, und die bringt mehr Probleme als Nutzen.
Das stimmt! Da muss man Windows _ausnahmsweise_ mal loben. Benutzerbezogene Anwendungsdaten kommen in das Verzeichnis \User\ \App Data\*
Dieses Verzeichnis kann man wunderbar excluden.
Wünsche mir seit Jahren auch so ein Verzeichnis unter Unix-Like-Systemen.
Sowas wie: /home/ /.application-data/*
Ich glaub als Unix damals entworfen wurde, hatte man noch nicht daran gedacht, dass es zig tausende Programme gibt auf einem System die alle das Home-Verzeichnis vollbomben.
Ach blöde HTML-Tags.
Meinte natürlich:
Windows: \User\[Benutzername]\App Data\
Unix: /home/[Benutzername]/.application-data/
Scheinbar beschätigt ihr euch nicht wirklich mit Linux, den ansonsten würdet wissen, dass dieses Verzeichnis schon seit geraumer Zeit existiert:
~/.config
Für Cache-Dateien gibt es das Verzeichnis "~/.cache".
Leider benutzen nicht sehr viele Programme diese beiden Verzeichnisse, aber die Anzahl derjenigen, die sie benutzen, wächst stetig. So legt z.B. Chrome/Chromium alle Konfigurationsdateien und Addons unter ".config" ab, der Cache wandert nach ".cache".
Ein Teil von GNOME ist z.B. schon umgestellt (Evolution benutzt beide Verzeichnisse), KDE benutzt es seit Version 4 (soviel ich weiß), viele andere Programme ebenfalls.
Es ist also nicht ein Problem des Systems, sondern der Programme bzw. der Entwickler. Diese müssten ihre Programme nur umstellen.
Dafür ist das Home-Verzeichnis aber da. Alle Benutzerdaten sollen darin liegen. Es ist das einzige Verzeichnis, in welchem der normale Benutzer normalerweise Schreibrechte hat. Anderswo hat er gefälligst nicht rumzupfuschen.Okay, die Verzeichnisse kenne ich in der Tat nicht. Freut mich das sowas eingeführt wurde.
Zu meiner Aussage, zur Konzeption: Es ist klar, das der Benutzer in seinem Home-Verzeichnis Schreibrechte hat um seine Daten abzulegen. Darunter stelle ich aber Dokumente, Bilder, Filme, usw. und nicht auf der selben Ebene dutzende bis tausende von Anwendungsordnern wo Anwendungen ihre Konfig-Daten sichern.
Wo sollen denn die Anwendungprogramme dann ihre Daten hinschreiben?
Unter Windows landen diese doch ebenfalls im passenden Benutzerverzeichnis, nur dort halt in einem Unterverzeichnis. Konzeptionell ändert sich aber nichts.
Naja, wo sollten Anwendungen ihre Config-Daten denn sonst speichern? Sowas gehoert ins Home. Wenn ich mein Home von nem anderen System mounte, dann will ich natuerlich auch dort meine anwendungsbezogenen Einstellungen haben. Ein Verzeichnis unabhaengig vom Home ist also Bloedsinn. Sowas unter .config und .cache abzulegen, also eine Ebene tiefer als das reine Home-Verzeichnis, macht aber schon Sinn. Denn meine Config will ich schon sichern, der Cache ist mir da aber nicht so wichtig
Ob diese Verzeichnisse verwendet werden ist glaub ich nicht mal so eine Frage der Anwendung, sondern des Frameworks. Soweit ich mich erinnern kann werden z.B. bei Qt-Programmen, die die entsprechenden Klassen des Frameworks fuer ihre Config verwenden, diese Daten eben unter .config gespeichert. Vielleicht muessten in erster Linie mal die Frameworks umgestellt werden...
Und für Programmdaten ~/.local/share
Alles Defaultwerte, überschreibbar mittels Umgebungsvariablen $XDG_CONFIG_HOME, $XDG_CACHE_HOME und $XDG_DATA_HOME
Siehe dazu auch http://standards.freedesktop.org/basedir-spec/latest/
Natürlich kann man Verzeichnisse/Dateien beim Backup ausschließen, warum auch nicht?
Schwer ist das auch nicht. Steht sowohl für tar als auch für rsync genau in der manpage drin.
Wenn du den Cache der User in /cache/$user haben willst, könntest du $XDG_CACHE_HOME in den Loginscripts oder über PAM eben auf diesen Wert setzen.
Wenn die Variable nicht gesetzt oder leer ist (was praktisch meistens der Fall ist), dann gehen Programme von $HOME/.cache aus.
D.h. alternativ kann man natürlich einen Symlink von /cache/user nach $HOME/.cache setzen.
WARUM kann man nicht erstmal versuchen zu verstehen worum es geth anstatt blödsinnige Threads ala warum nicht unter /tmp oder unter /var zu starten?
Anstatt endlich mit der Schweinerei im Linux Filesystem endlich aufzuräumen - Siehe (fast) Android, wird jetzt noch mehr davon erzeugt! Wieso müssen immer die Akademiker mit ihren, im Elfenbeinturm ersonnen, Spinnereien bei Linux den Ton angeben? Wie wärs zur Abwechslung mal wieder mit etwas Praxisbezug? Wieso wird immer gepachworkd? Zuerst die spinnerei mit isapnp (war schon vor Längerem), dann devfs, udev, hal, PolicyKit, sysfs, etc.). All diese Hacks versuchen nur Probleme zu lösen die in der grundlegenden Architektur von Linux/Unix begründet liegen. Als die Unix Standards gemacht wurden, hat eben niemand an usb, Webcams, DVD's, hotplug oä. gedacht. Das heisst das grundlegende Problem einer sauberen Hardware-Integration (und in diesem Fall, eines sauberen Boot-Prozederes) besteht noch immer, es werden lediglich Symptome bekämpft.
Wenn Linux schon nicht Unix ist, muss darauf auch nicht mehr Rücksicht genommen werden. Wie wäre es mal mit einem wirklich SAUBEREN Design und Implementierungs Refresh, welcher den Staub der letzten 20 Jahre wegwischt und das System in die Gegenwart bringt?
> Wieso müssen immer die Akademiker mit ihren, im Elfenbeinturm ersonnen
Spinnst du?
Diese Änderung wurde NICHT im Elfenbeinturm ersonnen sondern ist eine pragmatische Lösung, wäre sie im Elefenbeinturm ersonnen würde es noch 10 Jahre dauern bis sie beim Enduser ankommt