[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Index ueber Dateipool erzeugen (was: Re: file --preserve-date aendert die ctime und verstuemmelt die atime)
[Thread Prev] | [Thread Next]
- Subject: Index ueber Dateipool erzeugen (was: Re: file --preserve-date aendert die ctime und verstuemmelt die atime)
- From: Raphael Eiselstein <rabe@xxxxxxxxx>
- Date: Mon, 18 Nov 2013 00:43:26 +0100
- To: uugrn@xxxxxxxxxxxxxxx
On Thu, Nov 14, 2013 at 09:10:40PM +0100, Martin Marcher wrote: > > ctime veraendert worden. Das Ganze wird in sqlite ausgewertet > > Das klingt schon mehr nach Filesystem-Audit. Ich bin da bei Alexander, > aide oder ein sonstiges IDS bzw. audit-Framework vom OS zu verwenden > (wenn Audit die Richtung ist die das Tool erfuellen soll). Wie schon Freitag auf der Tonspur: Ziel ist es, einen (flachen) Index ueber einen groesseren Pool von Dateien zu bauen. In diesem Index sollen nicht nur unixoide Eigenschaften wie Groesse, Timestamps, User+Group, Permissions, Inode, â?¦ enthalten sein, sondern auch auf den *Inhalt* bezogene Eigenschaften. Primaerschluessel fuer den *Inhalt* einer Datei ist deren Checksumme, daher erfasse ich einmalig die Checksumme jeder Datei und ermittel dann nur *einmal* pro Checksumme die relevanten Eigenschaften wie z.B. * mime-type â?? mach ich aktuell bei jedem Aufruf ueber alle Files * Inhalte von Archiven, etwa tarballs, zip (und alle Dateiformate, die zip verwenden (jar, war, ear, â?¦)), rpm, deb, â?¦ * Multimedia-Dateien (jpeg::exif, mp3::id3, â?¦) * Dokumentformate Je nach zuvor ermitteldem mime-type faellt die Methode der jeweiligen Datei (Checksumme!) anders aus. Existiert eine inhaltlich identische Datei unter verschiedenen Namen oder in verschiedenen Verzeichnissen (Kopie oder Hardlink), dann muss deren Inhalt trotzdem nur einmal (teuer) analysiert werden. Das Script wird am Ende relativ universell nutzbar sein und der so erzeugte Index soll die Entwicklung von Tools vereinfachen, die fachlich auf dem Pool von Dateien operieren (zB Multimedia-Archiv, Repositories, â?¦). Viele dieser Tools traversieren heute auf eigene Faust durch einen Pool von Dateien auf der Suche nach fuer sie nutzbaren Informationen. Ist der Zugriff auf den Pool allerdings z.B. nur per FTP oder HTTP, dann kann das schon sehr haesslich werden, wenn man nicht auf einen quellseitigen vorkompilierten Index zurueckgreifen kann (zB FTP kennt die "ls-lR" Dateien) Gruss Raphael -- Raphael Eiselstein <rabe@xxxxxxxxx> http://rabe.uugrn.org/ xmpp:freibyter@xxxxxx | https://www.xing.com/profile/Raphael_Eiselstein PGP (alt): E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D PGP (neu): 4E63 5307 6F6A 036D 518D 3C4F 75EE EA14 F625 DB4E .........|.........|.........|.........|.........|.........|.........|.. -- UUGRN e.V. http://www.uugrn.org/ http://mailman.uugrn.org/mailman/listinfo/uugrn Wiki: https://wiki.uugrn.org/UUGRN:Mailingliste Archiv: http://lists.uugrn.org/