Suchergebnisse

Suchergebnisse 1-14 von insgesamt 14.

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • find tut, was der Name sagt. Es findet alle möglichen Dateien und Verzeichnisse. Ein sehr mächtiges Tool. Es kann auch für jeden Fund diverse Kommandos ausführen. Natürlich auch löschen. Das tut es aber ganz sicher nicht einfach so. Das müsste dann jemand wirklich willentlich gemacht haben. Wie kommst du darauf, dass find das machen würde? Wie schließt du aus, dass ein anderer Prozess das tut? Wenn du wirklich glaubst, dass du dir -auf welchem Wege auch immer- ein solches find - Kommando eingefa…

  • Ganz sicher nicht. Ganz sicher nicht hat dein Problem mit dem aktuellen Dateisystem zu tun. Auch die Pakete für Btrfs spielen keine Rolle. Die hängen halt ungenutzt im System rum. Es ist egal, ob ein Job via Cron oder via systemd.timer angestossen wird. Natürlich sind die Systemd.Timer modern, aber aus Kompatibilitätsgründen tun alle Cronjobs genau das Gleiche. Es bleibt gleich. Dein Systemd.Timer Listing zeigt nur Standardjobs. Kein Thema für dein Problem. Ob es ein Script gibt, das -egal ob vi…

  • borgbackup Ist open source, kostet also nichts. Dafür schreibt es auch via Netz vollständig deduplizierte Backups, sogar verschlüsselt und Spaswort geschützt, und bringt sogar ein Filesystem mit, womit man jeden verschlüsselten Backup einfach mounten kann. Es gibt derzeit nichts, was auch nur annähernd an borgbackup rankommt.

  • Halte ich für absolut ausgeschlossen. Es wäre das allererste Mal, dass irgendein Filesystem Tool Daten eines anderen Filesystems killt. Du hast ein anderes Problem.

  • Falls du recht hättest, warum lesen wir dann noch immer kein Ergebnis meines grep Kommandos?

  • Mal einfach die Scripte wenigsten beim Pfadnamen hier zu nennen, oder gar die entsprechenden Befehle hier tatsächlich zu posten, wäre keine Option? Es soll hier tatsächlich Leute geben, die sogar komplizierte Bashscripte flüssig zu lesen im Stande sind. Echt!

  • Nicht ein einziger find Befehl, der das machen würde. In keiner der geposteten Dateien. Auffällig ist, dass ziemlich überflüssige Windowsprogramme ihr Unwesen treiben. Zu solchem Müll äußere ich mich nicht. Das ist Ärger mit Ansage und Anlauf. Es ist mir auch egal, ob solcher Unsinn schuld an dem Desaster ist. Spiele, Transcoder, Packer Entwpacker... da bietet Linux besseres. (Außer bei Spielen vielleicht; dann sollte man die Windowsspiele aber auch unter Windows laufen lassen) Maybe, may be not…

  • Du hast Leap 42.3. KDE3 ist schon bei Leap 42.0 Steinzeit gewesen. Das konnte man nur noch in Museen bewundern. Längst läuft KDE4.x. Und vom aktuellen KDE gibt es keine Dateien in /opt. Die Frage, warum da /opt/kde3 rumliegt, wird also höchstens brisanter. (Es gibt schon einen Fork des alten KDE3; da hab ich den Namen aber schon wieder vergessen. Und hättest du den installiert, hättest du das jetzt hier geantwortet. Glaube ich also auch nicht.) Portable Programme? wozu das denn? Kehrst du die vo…

  • Nach deinen Schilderungen ist es noch fragwürdiger, warum in /opt ein KDE3 liegt. Das sollte also gar nicht da sein, da du, wie zu erwarten, ein "modernes" KDE4 installiert hst, also auch ein KDE lädst, falls du mal KDE startest. Keine Installation von egal welchem Leap erzeugt oder verwendet ein /opt/kde3 Verzeichnis. Die Frage nach dem portablen Programmen war eher spöttisch- zynisch. Ich sehe keinen Vorteil, ein Windowsprogramm auf einem Linuxrechner laufen zu lassen. Erst recht nicht, wenn e…

  • Genau, wie ich dachte: Dein Script tut exakt nichts, außer Rechenzeit zu verbraten. Du suchst mit pkill nach der e-xakten Kommandozeile find. Killen möchtest du aber einen Prozess mit einer Kommandozeile, wie z.B, find / -iname something -exec rm -rf {} \; Eine Kommandozeile die exakt nur "find" hat, tut genau nichts. Das gibt nicht einmal einen Fehler aus ob fehlender Parameter, das ordnungsgemäß nach Prozessen gesucht wird. Dass keiner gefunden wird, der dann gekillt werden könnte ist ja kein …

  • Ich habe von Anfang an gesagt, dass ich nicht glaube, dass du ein Problem mit einem find- Befehl hast, weil kein find- Befehl einfach löscht. Das war dir egal. Ich habe von Anfang an ebenfalls gesagt, dass es eine andere Ursache geben müsse. Das war dir egal. Also habe ich -nur damit du dich selbst überzeugen kannst- einen grep- Befehl gepostetet, er das Script finden würde, in dem ein solcher find- Befehl steht. Das war dir egal. Du machtest dir bislang nicht einmal die Mühe in Betracht zu zieh…

  • Denkbar ist ziemlich viel. Aber es zu finden ist unter diesen Voraussetzungen nicht sonderlich leicht. Man müsste da systematisch alles durchchecken. Das ginge aber nur, wenn auch aussagefähige Antworten gegeben würden. Um auf das "austauschen des Find- Befehls" zu kommen: Viele binäre Programme rufen ja eine Systemfunktion names "find" auf, die erst mal nichts mit dem Befehl selbst zu tun hat. (Und natürlich ruft der Find- Befehl selbst auch diese Systemroutinen auf.) Das kann man relativ leich…

  • Genau danach habe ich ja schon gesucht, indem ich ihn nach mehrmaliger Nachfrage doch dazu bewegen konnte, einen grep über alle Dateien zu machen. Ich hab das auch alles durchgelesen. Es gibt keinen solchen find Befehl auf der Platte. Wenn, dann wäre der irgendwie getürkt worden, oder eben dynamisch zusammengebastelt. Ein reguläre find Kommandozeile gibt es in keiner Datei im gesamten Tree nicht.

  • Zitat von albert_ernst: „Also, der Vorschlag von „ThomaS“ macht durchaus Sinn. Also werde ich die findutils ersetzen. Das ist mal ein guter Gedanke. Danke! “ Jou. Und genau in diesem Post hat @ThomasS mir recht gegeben. Und ein find löscht immer noch nicht. es findet. Da ist etwas anderes im Argen. Zitat von albert_ernst: „Und: wäre doch bitte mal jemand so grundgütig, um „Beleidigung“, nein, „Berichtigung“ zu erklären, dass EIN BENUTZER GRUPPE USERS NIEMALS SYTEMDATEIEN LÖSCHEN KANN, WENN NUR R…