[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Umgang mit Dubletten


Hallo Werner,

On Fri, Aug 21, 2009 at 05:28:37PM +0200, Werner Holtfreter wrote:
> > Das Basisverzeichnis dieses Repositorys sei ./.repo relativ zu
> > jedem Mointpoint, also zB /.repo /usr/.repo /home/.repo
> >
> > Unterhalb sei das repo nach den ersten 3 Stellen der Checksummen
> > untergliedert, damit nicht zu viele Dateien in einem Verzeichnis
> > liegen, ueber den Daumen gepeilt sind (bei Gleichverteilung) 256
> > Files pro Hierachieebene sinnvoll.
> 
> Warum ist das sinnvoll? Warum nicht alle Dateien in ein Verzeichnis?

Verzeichnisse, die sehr viele Dateien enthalten, sind langsamer im
Zugriff und darueber hinaus einfach unhandlich. 
 
> > Achso, Thema Doubletten: Die Treten im Repo nicht auf, koennen
> > aber im Homeverzeichnis entstehen.
> 
> Aber mein Ziel war doch, Dubletten im Home durch Links zu ersetzen!

Ja, aber Du willst moeglicherweise ausserdem sicherstellen, dass das 
Linkziel immer den Inhalt behaelt, den es beim Setzen des Links hatte. 
Ausgehend von meinem Beispiel waere z.B. sowas  machbar: Statt der Datei 
/home/rabe/UUGRN/Aufnahmeantrag_UUGRN.pdf ein Symlink setzen:

/home/rabe/UUGRN/Aufnahmeantrag_UUGRN.pdf -->
/.repo/e/55/e55d56d38035824cf1e2ead96e7688a72f3dac068d97e98d25fa819349a0cfae

Uebertragen auf Deinen Anwendungsfall:

1. Wiederholt vorkommende Dokumente, etwa PDF-Dokumente legst Du in 
das beschriebene Repository. Du hast damit nicht einen Dateinamen 
sondern einen ganz bestimmten Inhalt archiviert. Der Inhalt wird 
durch die Checksumme (Hash) repraesentiert.

2. Du verlinkst diesen Inhalt unter verschiedenen Arbeits- oder 
Projektverzeichnissen durch einen Symlink in das Repository. 
 
> Du hast zusaetzlich einen Index und ein Repository eingefuehrt. Das  
> Repository braucht nahezu keinen zusaetzlichen Platz, wenn es aus 
> Hardlinks auf die Dateien in Home besteht. Soweit gut. Aber wie 
> kann man mit diesem Konzept irgendwo Platz sparen und/oder 
> Uebersicht gewinnen?

Das Repository entspricht Deinem "SHARED"-Verzeichnis mit einem
gewissen Mehrwert, denn der Symlink auf
/.repo/e/55/e55d56d38035824cf1e2ead96e7688a72f3dac068d97e98d25fa819349a0cfae
wird immer den gleichen *Inhalt* referenzieren und nicht den gleichen
Dateinamen einer Datei, deren Inhalt prinzipiell aenderbar ist.

(...  sofern sicher[1] gestellt ist, dass sich der *Inhalt* von
/.repo/e/55/e55d56d38035824cf1e2ead96e7688a72f3dac068d97e98d25fa819349a0cfae
nicht aendern kann, was jedoch systematisch gecheckt werden kann.

> Sehr richtig. Wenn man inhaltsgleiche Dateien mit Hardlinks *blind* 
> verbinden wuerde, duerfte man darauf nur noch Lesezugriff zulassen 
> bzw. muesste beim Schreiben den Link loesen. Uebrigens werden durch 
> Hardlinks auch die Dateirechte vereinheitlicht, das nur am Rande.

Fuer r/o Zugriffe waere das aber auch nicht zu kompliziert, solange eine
Datei world-readable ist.  

Gruss
Raphael

PS: "sicher gestellt" im Sinne von "durch ein standardisiertes
Verfahren, welches prinzipbedingt geeignet ist" und nicht "sicher" im
kryptographischen Sinn.  Nur um weiteren Missverstaendnissen vorzubeugen.

-- 
Raphael Becker <rabe@xxxxxxxxx>                   http://rabe.uugrn.org/
                             https://www.xing.com/profile/Raphael_Becker
GnuPG:                E7B2 1D66 3AF2 EDC7 9828  6D7A 9CDA 3E7B 10CA 9F2D
.........|.........|.........|.........|.........|.........|.........|..



--
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: http://wiki.uugrn.org/wiki/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/