[solved] Dateien eindeutig markieren

OsunSeyi · 24 Feb. 2011

Hi,
Ist es prinzipiell möglich, eine Datei so eindeutig zu markieren, dass es auch dann möglich ist sie wiederzufinden, wenn sie geändert wurde?
Namensänderung natürlich inclusive ...sonst könnte man sich das ja sparen ;-)
Habe was von einer Inode-Nummer gehört, aber keine Ahnung.
Dann gibt es ja noch die drei Zeitstempel (erstellt, zuletzt zugegriffen, zuletzt geändert). Vielleicht kann man damit was drehen.

Im Moment praktiziere ich sowas, indem ein Script regelmässig (1s) schaut, was läuft:
Entweder der Name ist gleich, aber die Grösse hat sich geändert, das wird protokolliert.
Wurde die Datei dann verschoben (umbenannt), kann sie anhand der Grösse fast immer wiedergefunden werden.
Damit laufen hier zB Desktopstarter, die ihr Ziel 'verfolgen' können, und nicht verfallen, wenn die Datei verschoben wurde.
Das Verfahren ist aber ziemlich grottig.. es wäre halt cool, Dateien eindeutig markieren zu können.

viele Grüße
tom

Anonymous · 24 Feb. 2011

Solange eine Datei die selbe Inode hat ist es die selbe Datei. Auch wenn der Inhalt der Datei komplett überschrieben würde währe es die selbe Datei, eine Namensänderung, ein andere User, ein Verschieben innerhalb des Filesystems ändert daran nichts.

Das ändert sich wenn zb mit einem Texteditor die Datei geändert wird, dabei bekommt die Datei oftmals eine neue Inodenummer. Es handelt sich dabei streng genommen um eine andere Datei die nur aus dem Inhalt der alten Datei neu erstellt wurde.

Das selbe passiert wenn eine Datei über Filesystemgrenzen verschoben wird, dann wird dort auf dem Zielverzeichnis eine neue Datei erstellt. Die Inodenummer ist also nur innerhalb der jeweiligen Filesystemgrenzen eindeutig.

Du musst diese Datei im Filesystem nur über ihre Inodenummer suchen.

Das ganze ist aber trügerisch, sobald die Datei mal gelöscht wurde ist die Inodenummer frei und zur Wiederverwendung freigegeben. Sollte eine neue Datei im selben Verzeichnis mit genau dem selben Namen neu erzeugt werden, dann bekommt sie mit relativ hoher Wahrscheinlichkeit wieder die alte Inode und damit die alte Indodenummer, obwohl es dann eine andere Datei ist.

KLeines Beispiel (Konsollog) :

Code:

linux-vm-rob:/home/rob/testdir # for i in 1 2 3 4;do touch datei_$i; done
linux-vm-rob:/home/rob/testdir # ls -il
total 0
 90912 -rw-r--r-- 1 root root 0 2011-02-24 07:22 datei_1
102564 -rw-r--r-- 1 root root 0 2011-02-24 07:22 datei_2
102571 -rw-r--r-- 1 root root 0 2011-02-24 07:22 datei_3
102582 -rw-r--r-- 1 root root 0 2011-02-24 07:22 datei_4
linux-vm-rob:/home/rob/testdir # for i in 1 2 3 4; do echo hallo >> datei_$i; echo hallohallo > datei_$i; done
linux-vm-rob:/home/rob/testdir # for i in 1 2 3 4; do mv datei_$i neudatei_$i ; done
linux-vm-rob:/home/rob/testdir # cd /home
linux-vm-rob:/home # find -mount -inum 90912 2> /dev/null
./rob/testdir/neudatei_1

Es wird also hier die Datei mit der Inodenummer 90912 im ganzen Filesystem gesucht und wieder gefunden.

Im ext4 (und anderen neueren) Filesystem besteht theoretisch sogar die Möglichkeit eine Datei wirklich eindeutig zu verfolgen, und auszuschließen, das sie als die selbe Datei erkannt werden würde, obwohl die Inode in der Zwischenzeit schon mal gelöscht und wieder neu angelegt worden ist. das sind aber neue Inodeeigenschaften und wird derzeit noch nicht von libc unterstützt und ist damit mit normalen Befehlen auch nicht auslesbar. das könnte man zB über die create-time machen, die jede ext4 Datei jetzt schon hat, die sich aber noch niemand mit normalen Befehle anzeigen lassen kann.

Man müsste also derzeit (mit normalen Mitteln) um ganz sicher zu gehen das es sich wirklich um die selbe Datei handelt, verhindern können, das eine Datei gelöscht werden kann. Die Wahrscheinlichkeit ist unterschiedlich hoch, dass eine Neue Datei wieder die alte Inode bekommt, bei selben Namen im selben Verzeichnis eben relativ hoch. Das eine Datei mit einem anderem Namen in einem anderem Verzeichnis die selbe Inodenummer erhält, ist dagegen sehr viel weniger wahrscheinlich.

Übrigens

Dann gibt es ja noch die drei Zeitstempel (erstellt, zuletzt zugegriffen, zuletzt geändert).

ist falsch. Wir sind hier nicht in der Fensterwelt siehe

robi

OsunSeyi · 24 Feb. 2011

Vielen Dank für die ausführliche Antwort!

Das ändert sich wenn zb mit einem Texteditor die Datei geändert wird, dabei bekommt die Datei oftmals eine neue Inodenummer. Es handelt sich dabei streng genommen um eine andere Datei die nur aus dem Inhalt der alten Datei neu erstellt wurde.

Das ist es aber ja gerade, was man tut.
Das relativ blöde bei der Weiterverfolgerei ist, daß ich immer eine Datei halten muss, in der die Grösse (oder dann besser die Inodenummer) verzeichnet wird. Weil die sich ja mit dem Bearbeiten ändern kann.
Das Script schreibt bei jedem Durchgang den Namen und das Merkmal in diese Liste.
Ist die Datei woandershin verschoben, schaut es nach, welche Grösse (besser die Inodenummer) sie zuletzt hatte, sucht im Dateisystem danach und editiert den Desktopstarter. Funktioniert überraschend gut (manchmal aber auch nicht).
Hat aber eine gewisse CPU-Last, weil doch recht kompliziert. Und arbeitet zu 95% korrekt, aus verständlichen Gründen ist das ein eher behelsmässiges Verfahren.
Es ist halt nicht das gleiche wie ein eindeutiges Merkmal, das auch nach Bearbeitung oder umbenennen noch auffindbar ist.

panamajo · 24 Feb. 2011

OsunSeyi schrieb:
Dann gibt es ja noch die drei Zeitstempel (erstellt, zuletzt zugegriffen, zuletzt geändert).

Bei POSIX Dateisystemen gibt es idR. keinen Zeitstempel für "erstellt". Bei ctime steht das c für "changed" und bezieht sich auf den Inode wärend sich mtime (modified) auf den Inhalt der Datei bezieht.

Anonymous · 24 Feb. 2011

OsunSeyi schrieb:
Das ändert sich wenn zb mit einem Texteditor die Datei geändert wird, dabei bekommt die Datei oftmals eine neue Inodenummer. Es handelt sich dabei streng genommen um eine andere Datei die nur aus dem Inhalt der alten Datei neu erstellt wurde.

Das ist es aber ja gerade, was man tut.

Dann musst du die Leute nur zwingen den "richtigen Editor" zu nehmen, wenn du auch den Inhalt der Datei eindeutig verfolgen willst. Vi macht da keinerlei Probleme und bleibt bei der selben Inodenummer. Ist also bestens für Änderungen geeignet.

Code:

rob-linux:/tmp/test1 # ls -il README
661423 -rw-r--r-- 1 root root 1947 2011-02-24 20:15 README
rob-linux:/tmp/test1 # vi README
rob-linux:/tmp/test1 # ls -il README
661423 -rw-r--r-- 1 root root 24 2011-02-24 20:17 README

Wenn alle sich daran halten und nur mit ausgesuchten Befehlen arbeiten, kannst du deine Dateien bequem über die Inodenummer verfolgen.

Für ganz hartnäckige Fälle

Wenn sich einer deiner Pappenheimer querstellt und mit anderen Editoren arbeitet die dabei neue Dateien mit neuen Inodenummern erzeugen, dann wirst du noch eine Nummer rabiater und setzt eben auf die Dateien die du verfolgen willst ganz radikal das Imutable Flag und schreibst für die Änderungen dann kleine Scripte die es dann erlauben über sudo ausgeführt diese Dateien zu ändern, verschieben usw.
In den Scripten zuerst dieses Flag beseitigen, danach zB den ausgesuchten Editor mit dieser Datei aufrufen , oder die Umbenennungs oder Verschiebung der Datei ausführen und anschließend wieder das Imutable Flag setzen. Wenn sich die Datei nicht mehr anders ändern lässt, gewöhnen sich deine Pappenheimer schon daran, du kannst die Scripte ja auch so benennen und entsprechend im PATH ablegen, dass sie es nicht so schwer haben.

Code:

rob-linux:/tmp/test1 # chattr +i README
rob-linux:/tmp/test1 # ls -il README
661423 -rw-r--r-- 1 root root 24 2011-02-24 20:17 README
rob-linux:/tmp/test1 # rm README
rm: cannot remove `README': Die Operation ist nicht erlaubt

Diese Datei lässt sich nicht ändern auch nicht als root. Zum Ändern müssen dann immer die Scripte aufgerufen werden die das Ändern der Datei erlauben. Diese Scripte müssen für user dann über sudo als root ausgeführt werden. Ein solches Script zum Ändern des Inhaltes mal ganz einfach und ohne Absicherung und Überprüfung der Optionen.

Code:

rob-linux:/tmp/test1 # cat edit.sh
#!/bin/bash
#ganz einfaches Demoscript zum Ändern von Dateien

DATEI=$1
chattr -i $DATEI
vi $DATEI
chattr +i $DATEI

Aufgerufen als "./edit.sh README" lässt sich die Datei editieren und ist hierher wieder schreibgeschützt für alle. Alle anderen Änderungsversuche an dieser Datei dürfte deine User in den Wahnsinn treiben

Damit würdest du dir bestimmt keine Freunde machen, aber wo ein Wille ist immer auch ein Weg .

Dann kannst du auch innerhalb dieser Scripte die Änderungen in der Verfolgungsdatenbank vornehmen lassen und brauchst nicht mehr jede Sekunde das halbe System anzupollen, nur um nachzuschauen ob noch alles am richtigen Platz ist.

robi

OsunSeyi · 24 Feb. 2011

Hi,
das ist wirklich total interessant, aber ich arbeite an einem single-user-system, benutze niemals Vi und habe einfach nur Spass daran, dass meine Desktop-Starter (arbeite sehr Desktop-orientiert) ihre Gültigkeit auch dann behalten, wenn das ziel verschoben oder umbenannt wurde.
Mehr wirklich nicht...
Aber der Vorgang an sich, also in irgendeiner Form Dateien so abzulegen, wie es eben der Ordnung halber sein soll (dH in der Regel irgendwo tief vergraben nach Thema,Jahrgang usw) ist schon richtig, weil sich diese Dateien aufgrund der eher strengen Systematik auf jeden Fall leicht wiederfinden lassen.
Das aber wiederspricht irgendwo dem Wunsch, aktuelles direkt präsent zu haben.
Am besten in einer Art Projektordner. Datenbanken können sowas.
Wenn man aber die aktuelle Sachen auf dem Desktop hat, und die tatsächlichen Dateien im Hintergrund einsortieren kann, ohne daß die Starter ihre Gültigkeit verlieren, ist das fein.
Ich glaube aber, daß jemand, der eher über die Konsole arbeitet, diese Dinge anders sieht...?

Anonymous · 24 Feb. 2011

OsunSeyi schrieb:
Aber der Vorgang an sich, also in irgendeiner Form Dateien so abzulegen, wie es eben der Ordnung halber sein soll (dH in der Regel irgendwo tief vergraben nach Thema,Jahrgang usw) ist schon richtig, weil sich diese Dateien aufgrund der eher strengen Systematik auf jeden Fall leicht wiederfinden lassen.
Das aber wiederspricht irgendwo dem Wunsch, aktuelles direkt präsent zu haben.
Am besten in einer Art Projektordner. Datenbanken können sowas.

Dazu sind dann zB Links da. Die Orginaldatei ist dort wo sie hingehört, zB unterhalb von "/home/user/Bilder/privat/2009/Freundin/Urlaub/Portrait/...../Bild0001234.jpg" irgendwo fein einsortiert.
aber du kannst ja auch Hardlinks auf diese Datei dann in einem ganz anderem Verzeichnis anlegen zB als "/home/user/Bilder/aktuell/Eva.jpg"

Damit kannst du dir das Beste immer so hinlegen, das du es schnell wiederfindest und dort ein aufgeräumtes Bild ergeben und trotzdem die Orginale ständig anders einordnen und umräumen, wie du es gerade für Richtig hältst. Solange du die Dateien immer sauber verschiebst funktioniert das prima. Du hast das Bild nur einmal aber eben in verschiedenen Verzeichnissen Hardlinks auf die Bilder die dann auch im Bildnamen ganz anders sein können.
Meine Bildersammlungen sind zB über Hardlinks mehrfach sortiert. Somit habe ich in mehreren Verzeichnissen dann fertige Bildershows zu bestimmten Themen, während ich gleichzeitig die Bilder alle noch genau so sortiert habe, wie sie ursprünglich auf den Speicherkarten waren.
Kommt die Oma, wird das eine Verzeichnis abgespielt; kommen die Feunde, wird ein ganz anderes Verzeichnis abgespielt; und kommt eine neue Freundin, dann wird ein neues Verzeichnis angelegt und dort neue Hardlinks auf die Bilder erstellt.

Wenn ich der Meinung währe ich müsste hinten das Archiv umräumen, dann die Dateien nur verschieben oder umbenennen und die sortierten Verzeichnisse bleiben trotzdem so wie sie sind. Da brauche ich keine Datenbank dazu, nur etwas Disziplin auf dem eigenen Rechner.

robi

OsunSeyi · 25 Feb. 2011

Das trifft es genau!

Das ist in der Tat eine interessante Alternative, vielleicht kann man das Anlegen von Hardlinks via sudo auch dem normal-User gestatten.
Hab davon bisher praktisch keinen Gebrauch gemacht. Das setzt allerdings voraus, daß der Überblick darüber, was ein Hardlink ist und was nicht jederzeit klar ist (vielleicht direkt über die Namensgebung). Wie leicht ist sonst aus Versehen ein *vermeintlicher* Hardlink gelöscht...
Aber abgesehen davon:
Ob es eine Möglichkeit gibt, Dateien eindeutig zu markieren oder -noch besser- Dateibewegungen ganz allgemein nachvollziehen zu können, ist damit noch nicht ganz klar. Es gibt schließlich grafische Programme, die das leisten.

tom

Anonymous · 25 Feb. 2011

OsunSeyi schrieb:
Wie leicht ist sonst aus Versehen ein *vermeintlicher* Hardlink gelöscht...

Bei etwas Disziplin auf dem Rechner geht das gar nicht. Die Orginale bleiben wie sie sind, und dort sollte man eben nicht löschen, sondern nur verschieben und umbenennen. Dann kann man, wenn man will, von allen Dateien Hardlinks in einem anderem Verzeichnis erstellen und von diesen dann alles löschen was man in diesem Verzeichnis nicht braucht, den Rest umbenennen wie man will, bis es halt schön aussieht. Und dann wieder von allen Dateien Hardlinks in einem anderem Verzeichnis anlegen und dort auch alles löschen was man in diesem Verzeichnis nicht haben will und den Rest umbenennen und schon hast du aus einem unsortierten Dateisatz sortierte Dateien für 2 spezielle Themen gemacht.

Später beim Aufräumen dann in den Verzeichnissen in denen die ganze orginal-Sammlung ist, verschiebst du die Dateien und änderst dort die Namen solange bis dort alle sortiert sind. Am nächsten Tag kannst du dir bei Bedarf auch schon wieder eine neue Sortierung einfallen lassen und mit verschieben, umbenenne wieder alles umsortierten. Du kannst dort auch löschen, nur wenn vorher von dieser Datei kein Hardlink erzeugt wurde, dann ist diese Datei entgültig weg, aber absoluten Schrott, den man sowieso nicht benötigt, den löscht man dort. Deine schon vorher mit Hardlinks erstellen sortierten Verzeichnisse bleiben wie sie sind, dort ändert sich gar nichts.

Wenn dir ein sortiertes Verzeichnis nicht mehr gefällt, dann kannst du es auch komplett löschen, da brauchst du gar keine Rücksicht zu nehmen, wenn du das Filesystem so wie beschrieben sauber gepflegt hast, dann hast du dort nur Hardlinks und in den Orginalverzeichnissen hast du nur den absoluten Schrott gelöscht, also hast du überhaupt keinen Datenverlust wenn du ein solches sortiertes Verzeichniss voller Hardlinks löscht.

Übrigens Hardlinks können auch normale User anlegen. Sie benötigen nur entsprechend Schreibrechte auf die Datei und das Verzeichnis in das sie die Hardlinks erstellen möchten. Wieviele Hardlinks von einer Datei existieren kannst du dir mit "ls -l" anschauen. (die Zahl direkt hinter den Zugriffsrechten ist bei normalen Dateien die Anzahl der Hardlinks auf diese Datei, bei Verzeichnissen bedeutet diese Zahl etwas anderes, es sind aber auch bei Verzeichnissen streng genommen auch nur Hardlinks)
Es gibt auch kein Orginal und keine Kopien davon, das ist alles ein und das selbe und Hardlinks einer Datei sind absolut gleichberechtigt, das sind nur unterschiedliche Dateinamen in eventuell unterschiedlichen Verzeichnissen die auf ein und die selben Daten im Filesystem verweisen. Du kannst jeden Dateinamen einzeln Ändern und kannst ihn innerhalb des Filesystems frei hin und her verschieben. Jede Änderung am Inhalt würde sich sofort in allen Hardlinks beim Anzeigen bemerkbar machen. (unter der Voraussetzung das sich dabei die Inode nicht ändert, das ist bei Dokumenten und Multimediadateien meist bei den dort verwendeten grafischen Editoren nicht sichergestellt, so sollte man zB Photos bearbeiten sollte, bevor man einen Hardlink darauf erstellt, sonst würde der Hardlink weiterhin das Orginal beinhalten )
Auch jede Änderung (Schreibrechte oder Besitzverhältnisse) sind sofort bei allen aktiv. Wenn du also nicht willst, das ein User ein bestimmtes Bild öffen kann, dann kannst bei irgend einem der Hardlinks auf dieses Bild die Zugriffsrechte entsprechend ändern, der User kann dann ausprobieren was er will, alle Hardlinks von dieser Datei werden den Zugriff verweigern. Du kannst sie löschen wie du willst und in welcher Reihenfolge du das willst, erst wenn du den letzten Namen einer Datei Löscht, ist die Datei entgültig verschwunden. Welche Dateinamen auf die gleiche Dateiverweisen welche wird immer erst klar, wenn du dir die Inodenummern der Dateien anschaust.

Code:

ux-vm-rob:~/testdir> ls -al                                                                       
total 24                                                                                                 
drwxr-xr-x 2 rob users 4096 2011-02-24 07:24 .                                                           
drwxr-xr-x 7 rob users 4096 2011-02-24 07:11 ..                                                          
-rw-r--r-- 1 rob users   11 2011-02-24 07:23 neudatei_1                                                  
-rw-r--r-- 1 rob users   11 2011-02-24 07:23 neudatei_2                                                  
-rw-r--r-- 1 rob users   11 2011-02-24 07:23 neudatei_3                                                  
-rw-r--r-- 1 rob users   11 2011-02-24 07:23 neudatei_4                                                  
rob@linux-vm-rob:~/testdir> for i in neudatei* ; do ln $i link_$i ; done
rob@linux-vm-rob:~/testdir> ls -al                                      
total 40                                                                
drwxr-xr-x 2 rob users 4096 2011-02-25 08:39 .                          
drwxr-xr-x 7 rob users 4096 2011-02-24 07:11 ..                         
-rw-r--r-- 2 rob users   11 2011-02-24 07:23 link_neudatei_1            
-rw-r--r-- 2 rob users   11 2011-02-24 07:23 link_neudatei_2            
-rw-r--r-- 2 rob users   11 2011-02-24 07:23 link_neudatei_3            
-rw-r--r-- 2 rob users   11 2011-02-24 07:23 link_neudatei_4            
-rw-r--r-- 2 rob users   11 2011-02-24 07:23 neudatei_1                 
-rw-r--r-- 2 rob users   11 2011-02-24 07:23 neudatei_2                 
-rw-r--r-- 2 rob users   11 2011-02-24 07:23 neudatei_3                 
-rw-r--r-- 2 rob users   11 2011-02-24 07:23 neudatei_4                 
rob@linux-vm-rob:~/testdir> rm link_neudatei_[13]
rob@linux-vm-rob:~/testdir> mv link_neudatei_2 datei_2
rob@linux-vm-rob:~/testdir> ls -al
total 32
drwxr-xr-x 2 rob users 4096 2011-02-25 08:40 .
drwxr-xr-x 7 rob users 4096 2011-02-24 07:11 ..
-rw-r--r-- 2 rob users   11 2011-02-24 07:23 datei_2
-rw-r--r-- 2 rob users   11 2011-02-24 07:23 link_neudatei_4
-rw-r--r-- 1 rob users   11 2011-02-24 07:23 neudatei_1
-rw-r--r-- 2 rob users   11 2011-02-24 07:23 neudatei_2
-rw-r--r-- 1 rob users   11 2011-02-24 07:23 neudatei_3
-rw-r--r-- 2 rob users   11 2011-02-24 07:23 neudatei_4
rob@linux-vm-rob:~/testdir> ls -il
total 24
102564 -rw-r--r-- 2 rob users 11 2011-02-24 07:23 datei_2
102582 -rw-r--r-- 2 rob users 11 2011-02-24 07:23 link_neudatei_4
 90912 -rw-r--r-- 1 rob users 11 2011-02-24 07:23 neudatei_1
102564 -rw-r--r-- 2 rob users 11 2011-02-24 07:23 neudatei_2
102571 -rw-r--r-- 1 rob users 11 2011-02-24 07:23 neudatei_3
102582 -rw-r--r-- 2 rob users 11 2011-02-24 07:23 neudatei_4

robi

OsunSeyi · 26 Feb. 2011

Werde mal probieren, mich mit den Hardlinks anzufreunden...
Betreffs dem Nachverfolgen könnte ich mir folgendes vorstellen:

Das Script sucht (zB jede Sekunde) für jeden Link in meinem Projektordner, oder Desktopstarter, oder generell alle Links innerhalb meiner Produktivdateien (welch ein Anspruch) das Ziel, und merkt sich von diesem den Namen und die Pidnummer.
Warum nicht in einem Array in der Form:

Code:

eintrag[n]=01234/home/user/datei
  ...  sed 's/[[:digit:]]//g' ... usw

Wird die Quelldatei nun so bearbeitet, daß eine neue Pidnummer herauskommt, wird die alte überschrieben.
Innerhalb einer Sekunde wird die alte Pidnummer hoffentlich nicht neu belegt, bin selber ja am Bearbeiten.
Wird der Link ungültig (aufgrund Namensänderung der Quelle), kann der neue Pfadname anhand der Pidnummer leicht wiedergefunden werden.
Der Arrayeintrag wird erneuert, und ein neuer Link (mit altem Namen aber gültigen Ziel) wird angelegt.

Wenn man dies nun auch für Verzeichnisse hinbekäme, könnte man quasi das eigene Dateisystem patchen (mit den entsprechenden Scripten) oder Änderungen desselben rückgängig machen. Natürlich nicht für das ganze System oder /home...das ist schon klar.

Werd das mal versuchen umzusetzen (bei Gelegenheit, man sprach ja immerhin von 'Produktivdateien')

OsunSeyi · 28 Feb. 2011

Ok,
hab mal was probiert, was zu laufen scheint (Achtung!!!) auf jeden Fall muss das angepasst werden.
Wenn jemand das eleganter hinbekommt, wär schön.
Ansonsten noch: http://sudrala.de/de_d/shell-chglink.html

Code:

#!/bin/sh
# reloadLinks
#	Daemonartig, korrigiert Links auf Dateien alle 0,5 sec
#	'-cancel' beendet

# BEENDEN:

	if [ "$1" = '-cancel' ] ; then

#		'ps aux' gibt alle laufenden Prozesse aus, incl. Pfadname und Optionen.
#		'awk {print $2}' ist die pid:

		pid=`ps aux | egrep 'reloadLinks$' | awk '{print $2}'`
		kill $pid
		exit 0
	fi

#	Projektverzeichnis, in dem die Links liegen (mit Unterverzeichnissen):

	PROJ=/home/user/projektverzeichnis

#	Quellverzeichnis, in dem die Linkziele liegen (mit Unterverzeichnissen):

	FILES=/home/user/Quelldateien

#&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
 findling ()
 {
#	'$arr' sind die Links vom vorherigen Durchgang, wir brauchen das unten zum Auffinden verlorenen Linkziele:
#	'$ARR' wird bei jedem Durchgang neu geschrieben:

	arr=$ARR
	ARR=''

#	Wir wechseln in das Projektverzeichnis:

	cd $PROJ

#	Für jeden Link von hier abwärts:

	for link in `find $PWD -type l` ; do

#	wechseln wir zunächst in das betreffende Projektunterverzeichnis,
#	das müssen wir, um den relativ angegebenen Pfaden von 'ls -l' folgen
#	zu können:

		cd `echo $link | sed 's|/[^/]\+$||g'`

#	'ls -l' gibt den relativen Pfad zum Linkziel aus:

		pathrel=`ls -l $link | awk '{print $10}'`

#	'$inode', die Inode-Nummer der Zieldatei:

		inode=`ls -i $pathrel 2>/dev/null | sed 's|^\([[:digit:]]\+\).*$|\1|g'`

#	zum testen:
#		echo $inode$link

#	Ist unser Link ungültig geworden, zeigt er nicht mehr auf eine Datei, also
#	kann hier auch keine Inodenummer ankommen:

		if [ -z "$inode" ] ; then

#	Wir suche den Brokenlink in unserem Vergleichsarray:

			for item in $arr ; do

				inodebroken=`echo $item | grep $link | sed 's|/.*$||g'`

#	Wurde die zu unserem Brokenlink gehörende Inodenummer gefunden, suche
#	mit 'find' unser neues Linkziel:

				if [ -n "$inodebroken" ] ; then

					newlink=`find $FILES -inum $inodebroken`
					ln -s -f $newlink $link
				fi
			done
		fi

#	Unser Array zum vergleichen, ob alle Linkziele noch stimmen:

		ARR=$ARR' '$inode$link

	done
 }
#&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

while [ 1=1 ] ; do

	findling &&
	sleep 0.5	# eine Veränderung des Wertes beeinflusst die Last

#	zum testen:
#		read

done
exit 0

EDIT
Teste das mitterweile, es können noch Fehler drin die sich aber korrigireren lassen.
Für mich ist ein Script, was Softlinks regelmässig aktuell hält, angenehmer als ein Einsatz von Hardlinks als 'normale' Arbeitsweise.
Es wird andernorts betreffs Hardlinks oft gesagt, man solle sie eher sparsam einsetzen.
Allerdings leuchtet mir Deine Erleuterung, daß dies eine Frage der Disziplin am Rechner ist wohl ein.
Jeder hat seine Methoden.
Übrigens finde ich Softlinks, die ihr Ziel 'verfolgen' können, nachgeradezu überfällig...

[solved] Dateien eindeutig markieren

OsunSeyi

Anonymous

Gast

OsunSeyi

panamajo

Anonymous

Gast

OsunSeyi

Anonymous

Gast

OsunSeyi

Anonymous

Gast

OsunSeyi

OsunSeyi