1.1 --- a/es/concepts.tex	Tue Nov 18 22:48:55 2008 -0500
     1.2 +++ b/es/concepts.tex	Thu Nov 20 00:11:23 2008 -0500
     1.3 @@ -515,18 +515,20 @@
     1.4  recomprmime el flujo, porque \command{ssh} puede hacer esto por sí
     1.5  mismo.)
     1.6  
     1.7 -\subsection{Read/write ordering and atomicity}
     1.8 -
     1.9 -Appending to files isn't the whole story when it comes to guaranteeing
    1.10 -that a reader won't see a partial write.  If you recall
    1.11 -figure~\ref{fig:concepts:metadata}, revisions in the changelog point to
    1.12 -revisions in the manifest, and revisions in the manifest point to
    1.13 -revisions in filelogs.  This hierarchy is deliberate.
    1.14 -
    1.15 -A writer starts a transaction by writing filelog and manifest data,
    1.16 -and doesn't write any changelog data until those are finished.  A
    1.17 -reader starts by reading changelog data, then manifest data, followed
    1.18 -by filelog data.
    1.19 +\subsection{Reordenado de lectura/escritura y atomicidad}
    1.20 +
    1.21 +Añadir datos al final de un fichero no es todo lo que hace falta para
    1.22 +garantizar que un lector no verá una escritura parcial. Si recuerda la
    1.23 +figura~\ref{fig:concepts:metadata}, las revisiones en la bitácora de
    1.24 +cambios apuntan a revisiones en el manifiesto, y las revisiones en el
    1.25 +manifiesto apuntan a revisiones en ficheros de registro. Esta
    1.26 +jerarquía es deliberada.
    1.27 +
    1.28 +Un escritor inicia una transacción al escribir los datos del ficheros
    1.29 +del fichero de registro y el manifiesto, y no escribe nada en la
    1.30 +bitácora de cambios hasta que dichas escrituras hayan terminado. Un
    1.31 +lector empieza leyendo datos de la bitácora de cambios, luego del
    1.32 +manifiesto, y finalmente del fichero de registro.
    1.33  
    1.34  Since the writer has always finished writing filelog and manifest data
    1.35  before it writes to the changelog, a reader will never read a pointer