rt/snapraid
1
0
Fork 0
mirror of https://github.com/amadvance/snapraid.git synced 2026-10-26 10:51:54 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

Implement two-phase file scan with dedicated discovery struct and volatile hardlink normalization

Browse source
This commit is contained in:
Andrea Mazzoleni 2026-09-07 17:16:24 +02:00
parent b113accaad
commit 12c41ff1d1
45 changed files with 1443 additions and 960 deletions
Download patch file Download diff file Expand all files Collapse all files

2
cmdline/elem.c
View file

@ -497,7 +497,6 @@ struct snapraid_file* file_alloc(unsigned block_size, const char* sub, data_off_
file->inode = inode;
file->physical = physical;
file->flag = 0;
file->shared_flag = 0;
file->blockvec = nalloc_nofail((size_t)file->blockmax, block_sizeof());
for (i = 0; i < file->blockmax; ++i) {
@ -532,7 +531,6 @@ struct snapraid_file* file_dup(struct snapraid_file* copy)
file->inode = copy->inode;
file->physical = copy->physical;
file->flag = copy->flag;
file->shared_flag = 0;
file->blockvec = nalloc_nofail((size_t)file->blockmax, block_sizeof());
for (i = 0; i < file->blockmax; ++i) {

37
cmdline/elem.h
View file

@ -312,18 +312,14 @@ struct snapraid_block {
#define FILE_IS_REALLOC_NEW 0x80000
/**
* Flags from this bit are shared between multiple threads
* and goes in the shared_flags instead of flags
* Flag to indicate that an existing file was discovered on the disk during Phase 1.
*/
#define FILE_FLAGS_SHARED_BIT 24
#define FILE_IS_DISCOVERED 0x100000
/**
* During scan if the file is found missing and relocated to another place
*
* This is used to avoid to report it "removed".
*
* This specific bit is written using protection from the stamp_mutex during
* the multithread scan.
*/
#define FILE_IS_RELOCATED 0x1000000
@ -340,7 +336,6 @@ struct snapraid_file {
char* sub; /**< Sub path of the file. Without the disk dir. The disk is implicit. */
int mtime_nsec; /**< Modification time nanoseconds. In the range 0 <= x < 1,000,000,000, or STAT_NSEC_INVALID if not present. */
uint32_t flag; /**< FILE_IS_* flags. */
uint32_t shared_flag; /**< FILE_IS_RELOCATED flag. Keep it separated as it's accessed by multiple threads */
/* nodes for data structures */
tommy_node nodelist;
@ -494,16 +489,6 @@ struct snapraid_disk {
*/
thread_mutex_t fs_mutex;
/**
* Mutex for protecting the scan process.
*
* It's used during the scan process to protect the stampset to identify copy of files
* and the FILE_IS_RELOCATED flag of files.
*
* Note that only the FILE_IS_RELOCATED single bit is protected.
* Not the other bits.
*/
thread_mutex_t stamp_mutex;
#endif
/**
@ -886,29 +871,17 @@ static inline int block_has_reallocatable_parity(const struct snapraid_block* bl
static inline int file_flag_has(const struct snapraid_file* file, unsigned mask)
{
if (mask >= (1U << FILE_FLAGS_SHARED_BIT)) {
return (file->shared_flag & mask) == mask;
} else {
return (file->flag & mask) == mask;
}
return (file->flag & mask) == mask;
}
static inline void file_flag_set(struct snapraid_file* file, unsigned mask)
{
if (mask >= (1U << FILE_FLAGS_SHARED_BIT)) {
file->shared_flag |= mask;
} else {
file->flag |= mask;
}
file->flag |= mask;
}
static inline void file_flag_clear(struct snapraid_file* file, unsigned mask)
{
if (mask >= (1U << FILE_FLAGS_SHARED_BIT)) {
file->shared_flag &= ~mask;
} else {
file->flag &= ~mask;
}
file->flag &= ~mask;
}
/**

688
cmdline/scan.c
View file

File diff suppressed because it is too large Load diff

39
doc/snapraid-de.1
View file

@ -2437,21 +2437,6 @@ einen Mount\-Punkt verdeckt war.
.PP
Platzieren Sie keine verschachtelten Mount\-Punkte oder Bind\-Mounts innerhalb
von Datenfestplatten, wenn Dateisystem\-Snapshots aktiviert sind.
.SS Hardlinks
SnapRAID identifiziert einen Hardlink als Originaldatei und stellt die
anderen Hardlinks als Verweise darauf dar. Welcher Link als Originaldatei
ausgewählt wird, hängt von der Reihenfolge ab, in der Verzeichniseinträge
gescannt werden.
.PP
Wenn sich diese Reihenfolge ändert, beispielsweise nach dem Umbenennen,
Wiederherstellen von Dateien oder Neuerstellen von Verzeichnissen, meldet
\[dq]diff\[dq] möglicherweise scheinbare Verschiebungen, Aktualisierungen,
Hinzufügungen oder Entfernungen, selbst wenn die fest verknüpften Dateien
immer noch dieselben Daten darstellen.
.PP
Dies deutet nicht auf eine Datenbeschädigung hin, aber die gemeldeten
Unterschiede können verwirrend sein und stimmen möglicherweise nicht direkt
mit den ausgeführten Dateisystemoperationen überein.
.SS In\-Place\-Dateimodifikationen ohne Zeitstempeländerungen
SnapRAID erkennt Dateimodifikationen durch den Vergleich von Dateigrößen
und Änderungszeitstempeln (mtime).
@ -2529,6 +2514,30 @@ Wiederherstellung gedacht, typischerweise nachdem ein normaler \`fix\`
fehlgeschlagen ist. Wenn ein partieller \`fix\` nicht wiederherstellbare Daten
meldet, entfernen oder benennen Sie die betroffenen Dateien um, bevor Sie eine
weitere Wiederherstellung versuchen, oder überprüfen Sie deren Inhalt manuell.
.SS NTFS\-Hardlinks und ausgeschlossene Pfade
Unter NTFS speichern Verzeichniseinträge Dateigröße und Zeitstempel
unabhängig für jeden Hardlink zwischen. Wenn eine Datei über einen Link
geändert wird, können die Verzeichniseinträge anderer Links, die auf
dieselbe Datei verweisen, veraltete Metadaten behalten, bis auf sie
zugegriffen wird.
.PP
SnapRAID erkennt und normalisiert diesen Zustand automatisch, sobald
während eines Scans mindestens zwei Hardlinks zu derselben Datei gefunden
werden. Wenn jedoch nur ein Hardlink gescannt wird, während die anderen
durch Filter ausgeschlossen sind oder außerhalb des Datenfestplattenpfads
liegen, kann SnapRAID die Inode\-Kollision nicht erkennen und verlässt sich
auf die zwischengespeicherten Metadaten des einzigen sichtbaren Links.
.PP
Infolgedessen können Änderungen, die über einen ausgeschlossenen oder
externen Hardlink vorgenommen wurden, von SnapRAID unbemerkt bleiben,
bis die Metadaten des einbezogenen Links durch das Betriebssystem
aktualisiert werden (z. B. wenn über diesen Pfad auf die Datei
zugegriffen oder sie geöffnet wird).
.PP
Um diese Einschränkung zu vermeiden, sollten geschützte Dateien nicht über
Hardlinks geändert werden, die von SnapRAID ausgeschlossen sind, oder es
sollte sichergestellt werden, dass alle Hardlinks zu einer Datei im Scan
enthalten sind, damit SnapRAID sie normalisieren kann.
.SH ÜBERSETZUNG (TRANSLATION)
Dieses Dokument ist eine automatische Übersetzung des englischen Handbuchs.
Die maßgebliche Version finden Sie im englischen Handbuch.

41
doc/snapraid-de.d
View file

@ -1924,22 +1924,6 @@ Bekannte Probleme (Known Issues)
Platzieren Sie keine verschachtelten Mount-Punkte oder Bind-Mounts innerhalb
von Datenfestplatten, wenn Dateisystem-Snapshots aktiviert sind.
Hardlinks
SnapRAID identifiziert einen Hardlink als Originaldatei und stellt die
anderen Hardlinks als Verweise darauf dar. Welcher Link als Originaldatei
ausgewählt wird, hängt von der Reihenfolge ab, in der Verzeichniseinträge
gescannt werden.
Wenn sich diese Reihenfolge ändert, beispielsweise nach dem Umbenennen,
Wiederherstellen von Dateien oder Neuerstellen von Verzeichnissen, meldet
"diff" möglicherweise scheinbare Verschiebungen, Aktualisierungen,
Hinzufügungen oder Entfernungen, selbst wenn die fest verknüpften Dateien
immer noch dieselben Daten darstellen.
Dies deutet nicht auf eine Datenbeschädigung hin, aber die gemeldeten
Unterschiede können verwirrend sein und stimmen möglicherweise nicht direkt
mit den ausgeführten Dateisystemoperationen überein.
In-Place-Dateimodifikationen ohne Zeitstempeländerungen
SnapRAID erkennt Dateimodifikationen durch den Vergleich von Dateigrößen
und Änderungszeitstempeln (mtime).
@ -2021,6 +2005,31 @@ Bekannte Probleme (Known Issues)
meldet, entfernen oder benennen Sie die betroffenen Dateien um, bevor Sie eine
weitere Wiederherstellung versuchen, oder überprüfen Sie deren Inhalt manuell.
NTFS-Hardlinks und ausgeschlossene Pfade
Unter NTFS speichern Verzeichniseinträge Dateigröße und Zeitstempel
unabhängig für jeden Hardlink zwischen. Wenn eine Datei über einen Link
geändert wird, können die Verzeichniseinträge anderer Links, die auf
dieselbe Datei verweisen, veraltete Metadaten behalten, bis auf sie
zugegriffen wird.
SnapRAID erkennt und normalisiert diesen Zustand automatisch, sobald
während eines Scans mindestens zwei Hardlinks zu derselben Datei gefunden
werden. Wenn jedoch nur ein Hardlink gescannt wird, während die anderen
durch Filter ausgeschlossen sind oder außerhalb des Datenfestplattenpfads
liegen, kann SnapRAID die Inode-Kollision nicht erkennen und verlässt sich
auf die zwischengespeicherten Metadaten des einzigen sichtbaren Links.
Infolgedessen können Änderungen, die über einen ausgeschlossenen oder
externen Hardlink vorgenommen wurden, von SnapRAID unbemerkt bleiben,
bis die Metadaten des einbezogenen Links durch das Betriebssystem
aktualisiert werden (z. B. wenn über diesen Pfad auf die Datei
zugegriffen oder sie geöffnet wird).
Um diese Einschränkung zu vermeiden, sollten geschützte Dateien nicht über
Hardlinks geändert werden, die von SnapRAID ausgeschlossen sind, oder es
sollte sichergestellt werden, dass alle Hardlinks zu einer Datei im Scan
enthalten sind, damit SnapRAID sie normalisieren kann.
Übersetzung (Translation)
Dieses Dokument ist eine automatische Übersetzung des englischen Handbuchs.
Die maßgebliche Version finden Sie im englischen Handbuch.

53
doc/snapraid-de.txt
View file

@ -2059,25 +2059,7 @@ einen Mount-Punkt verdeckt war.
Platzieren Sie keine verschachtelten Mount-Punkte oder Bind-Mounts innerhalb
von Datenfestplatten, wenn Dateisystem-Snapshots aktiviert sind.
16.3 Hardlinks
--------------
SnapRAID identifiziert einen Hardlink als Originaldatei und stellt die
anderen Hardlinks als Verweise darauf dar. Welcher Link als Originaldatei
ausgewählt wird, hängt von der Reihenfolge ab, in der Verzeichniseinträge
gescannt werden.
Wenn sich diese Reihenfolge ändert, beispielsweise nach dem Umbenennen,
Wiederherstellen von Dateien oder Neuerstellen von Verzeichnissen, meldet
"diff" möglicherweise scheinbare Verschiebungen, Aktualisierungen,
Hinzufügungen oder Entfernungen, selbst wenn die fest verknüpften Dateien
immer noch dieselben Daten darstellen.
Dies deutet nicht auf eine Datenbeschädigung hin, aber die gemeldeten
Unterschiede können verwirrend sein und stimmen möglicherweise nicht direkt
mit den ausgeführten Dateisystemoperationen überein.
16.4 In-Place-Dateimodifikationen ohne Zeitstempeländerungen
16.3 In-Place-Dateimodifikationen ohne Zeitstempeländerungen
------------------------------------------------------------
SnapRAID erkennt Dateimodifikationen durch den Vergleich von Dateigrößen
@ -2093,7 +2075,7 @@ Sie den Änderungszeitstempel der Datei (z. B. mit dem Dienstprogramm "touch").
Andernfalls wird der Unterschied erst bei einem nachfolgenden "scrub" oder
"check" als Hash-Fehlübereinstimmung erkannt.
16.5 Nicht-ASCII-Groß-/Kleinschreibung unter Windows
16.4 Nicht-ASCII-Groß-/Kleinschreibung unter Windows
----------------------------------------------------
SnapRAID verwendet auf allen Plattformen eine standardmäßige, vorhersehbare
@ -2116,7 +2098,7 @@ verursacht. Um Abweichungen durch das Case-Folding von Windows zu vermeiden,
geben Sie für alle Nicht-ASCII-Zeichen in Konfigurationspfaden und Filtern
stets die exakte Groß-/Kleinschreibung an.
16.6 Dateiendung für nicht wiederherstellbare Dateien
16.5 Dateiendung für nicht wiederherstellbare Dateien
-----------------------------------------------------
Wenn `fix` eine beschädigte Datei nicht vollständig wiederherstellen kann,
@ -2142,7 +2124,7 @@ Dateien und stellen Sie sicher, dass `exclude *.unrecoverable` in Ihrer
Konfiguration enthalten ist, um zu verhindern, dass solche Dateien im
Paritätsdatensatz erfasst werden.
16.7 Wiederherstellung mit partiellem Fix
16.6 Wiederherstellung mit partiellem Fix
-----------------------------------------
Wenn `fix` mit `-S, --start` oder `-B, --count` eingeschränkt wird,
@ -2166,6 +2148,33 @@ fehlgeschlagen ist. Wenn ein partieller `fix` nicht wiederherstellbare Daten
meldet, entfernen oder benennen Sie die betroffenen Dateien um, bevor Sie eine
weitere Wiederherstellung versuchen, oder überprüfen Sie deren Inhalt manuell.
16.7 NTFS-Hardlinks und ausgeschlossene Pfade
---------------------------------------------
Unter NTFS speichern Verzeichniseinträge Dateigröße und Zeitstempel
unabhängig für jeden Hardlink zwischen. Wenn eine Datei über einen Link
geändert wird, können die Verzeichniseinträge anderer Links, die auf
dieselbe Datei verweisen, veraltete Metadaten behalten, bis auf sie
zugegriffen wird.
SnapRAID erkennt und normalisiert diesen Zustand automatisch, sobald
während eines Scans mindestens zwei Hardlinks zu derselben Datei gefunden
werden. Wenn jedoch nur ein Hardlink gescannt wird, während die anderen
durch Filter ausgeschlossen sind oder außerhalb des Datenfestplattenpfads
liegen, kann SnapRAID die Inode-Kollision nicht erkennen und verlässt sich
auf die zwischengespeicherten Metadaten des einzigen sichtbaren Links.
Infolgedessen können Änderungen, die über einen ausgeschlossenen oder
externen Hardlink vorgenommen wurden, von SnapRAID unbemerkt bleiben,
bis die Metadaten des einbezogenen Links durch das Betriebssystem
aktualisiert werden (z. B. wenn über diesen Pfad auf die Datei
zugegriffen oder sie geöffnet wird).
Um diese Einschränkung zu vermeiden, sollten geschützte Dateien nicht über
Hardlinks geändert werden, die von SnapRAID ausgeschlossen sind, oder es
sollte sichergestellt werden, dass alle Hardlinks zu einer Datei im Scan
enthalten sind, damit SnapRAID sie normalisieren kann.
17 ÜBERSETZUNG (TRANSLATION)
============================

37
doc/snapraid-es.1
View file

@ -2393,20 +2393,6 @@ hacerse visible.
.PP
No coloque puntos de montaje anidados ni montajes bind dentro de los discos
de datos cuando las instantáneas del sistema de archivos estén habilitadas.
.SS Enlaces duros
SnapRAID identifica un enlace duro como el archivo original y representa
los demás enlaces duros como referencias a él. El enlace que se selecciona
como archivo original depende del orden en que se escanean las entradas del
directorio.
.PP
Si este orden cambia, por ejemplo después de renombrar, restaurar archivos o
recrear directorios, \[dq]diff\[dq] puede informar movimientos, actualizaciones,
adiciones o eliminaciones aparentes incluso cuando los archivos vinculados
siguen representando los mismos datos.
.PP
Esto no indica corrupción de datos, pero las diferencias informadas pueden
resultar confusas y no corresponder directamente con las operaciones
realizadas en el sistema de archivos.
.SS Modificaciones de archivos in situ sin cambios de marca de tiempo
SnapRAID detecta modificaciones de archivos comparando tamaños de archivo y
marcas de tiempo de modificación (mtime).
@ -2478,6 +2464,29 @@ Las opciones \`\-S\` y \`\-B\` están destinadas únicamente a la recuperación
avanzada, típicamente después de que un \`fix\` normal haya fallado. Si un \`fix\`
parcial informa de datos no recuperables, elimine o renombre los archivos
afectados antes de intentar otra recuperación, o verifique su contenido manualmente.
.SS Enlaces duros en NTFS y rutas excluidas
En NTFS, las entradas de directorio almacenan en caché el tamaño del
archivo y las marcas de tiempo de forma independiente para cada enlace
duro. Cuando un archivo se modifica a través de un enlace, las entradas
de directorio de otros enlaces que apuntan al mismo archivo pueden
conservar metadatos obsoletos hasta que se accede a ellos.
.PP
SnapRAID detecta y normaliza automáticamente esta condición siempre que
se encuentran al menos dos enlaces duros al mismo archivo durante un
escaneo. Sin embargo, si solo se escanea un enlace duro mientras los
demás están excluidos por filtros o se encuentran fuera de la ruta del
disco de datos, SnapRAID no puede detectar la colisión de inodos y confía
en los metadatos almacenados en caché del único enlace visible.
.PP
En consecuencia, las modificaciones realizadas a través de un enlace duro
excluido o externo pueden pasar desapercibidas para SnapRAID hasta que el
sistema operativo actualice los metadatos del enlace incluido (como cuando
se accede al archivo o se abre a través de esa ruta).
.PP
Para evitar esta limitación, evite modificar archivos protegidos a través
de enlaces duros que estén excluidos de SnapRAID, o asegúrese de que
todos los enlaces duros a un archivo se incluyan en el escaneo para que
SnapRAID pueda normalizarlos.
.SH TRADUCCIóN (TRANSLATION)
Este documento es una traducción automática del manual en inglés.
Consulte el manual en inglés para obtener la versión oficial.

39
doc/snapraid-es.d
View file

@ -1891,21 +1891,6 @@ Problemas conocidos (Known Issues)
No coloque puntos de montaje anidados ni montajes bind dentro de los discos
de datos cuando las instantáneas del sistema de archivos estén habilitadas.
Enlaces duros
SnapRAID identifica un enlace duro como el archivo original y representa
los demás enlaces duros como referencias a él. El enlace que se selecciona
como archivo original depende del orden en que se escanean las entradas del
directorio.
Si este orden cambia, por ejemplo después de renombrar, restaurar archivos o
recrear directorios, "diff" puede informar movimientos, actualizaciones,
adiciones o eliminaciones aparentes incluso cuando los archivos vinculados
siguen representando los mismos datos.
Esto no indica corrupción de datos, pero las diferencias informadas pueden
resultar confusas y no corresponder directamente con las operaciones
realizadas en el sistema de archivos.
Modificaciones de archivos in situ sin cambios de marca de tiempo
SnapRAID detecta modificaciones de archivos comparando tamaños de archivo y
marcas de tiempo de modificación (mtime).
@ -1981,6 +1966,30 @@ Problemas conocidos (Known Issues)
parcial informa de datos no recuperables, elimine o renombre los archivos
afectados antes de intentar otra recuperación, o verifique su contenido manualmente.
Enlaces duros en NTFS y rutas excluidas
En NTFS, las entradas de directorio almacenan en caché el tamaño del
archivo y las marcas de tiempo de forma independiente para cada enlace
duro. Cuando un archivo se modifica a través de un enlace, las entradas
de directorio de otros enlaces que apuntan al mismo archivo pueden
conservar metadatos obsoletos hasta que se accede a ellos.
SnapRAID detecta y normaliza automáticamente esta condición siempre que
se encuentran al menos dos enlaces duros al mismo archivo durante un
escaneo. Sin embargo, si solo se escanea un enlace duro mientras los
demás están excluidos por filtros o se encuentran fuera de la ruta del
disco de datos, SnapRAID no puede detectar la colisión de inodos y confía
en los metadatos almacenados en caché del único enlace visible.
En consecuencia, las modificaciones realizadas a través de un enlace duro
excluido o externo pueden pasar desapercibidas para SnapRAID hasta que el
sistema operativo actualice los metadatos del enlace incluido (como cuando
se accede al archivo o se abre a través de esa ruta).
Para evitar esta limitación, evite modificar archivos protegidos a través
de enlaces duros que estén excluidos de SnapRAID, o asegúrese de que
todos los enlaces duros a un archivo se incluyan en el escaneo para que
SnapRAID pueda normalizarlos.
Traducción (Translation)
Este documento es una traducción automática del manual en inglés.
Consulte el manual en inglés para obtener la versión oficial.

51
doc/snapraid-es.txt
View file

@ -2026,24 +2026,7 @@ hacerse visible.
No coloque puntos de montaje anidados ni montajes bind dentro de los discos
de datos cuando las instantáneas del sistema de archivos estén habilitadas.
16.3 Enlaces duros
------------------
SnapRAID identifica un enlace duro como el archivo original y representa
los demás enlaces duros como referencias a él. El enlace que se selecciona
como archivo original depende del orden en que se escanean las entradas del
directorio.
Si este orden cambia, por ejemplo después de renombrar, restaurar archivos o
recrear directorios, "diff" puede informar movimientos, actualizaciones,
adiciones o eliminaciones aparentes incluso cuando los archivos vinculados
siguen representando los mismos datos.
Esto no indica corrupción de datos, pero las diferencias informadas pueden
resultar confusas y no corresponder directamente con las operaciones
realizadas en el sistema de archivos.
16.4 Modificaciones de archivos in situ sin cambios de marca de tiempo
16.3 Modificaciones de archivos in situ sin cambios de marca de tiempo
----------------------------------------------------------------------
SnapRAID detecta modificaciones de archivos comparando tamaños de archivo y
@ -2058,7 +2041,7 @@ de tiempo de modificación del archivo (por ejemplo, con la utilidad "touch").
De lo contrario, la diferencia solo se detectará como una falta de
coincidencia de hash durante un "scrub" o "check" posterior.
16.5 Coincidencia de mayúsculas y minúsculas no ASCII en Windows
16.4 Coincidencia de mayúsculas y minúsculas no ASCII en Windows
----------------------------------------------------------------
SnapRAID utiliza una codificación UTF-8 estándar y predecible en todas las
@ -2082,7 +2065,7 @@ mayúsculas y minúsculas. Para evitar discrepancias derivadas del plegado de
mayúsculas y minúsculas de Windows, especifique siempre la grafía exacta de
los caracteres no ASCII en las rutas de configuración y filtros.
16.6 Sufijo de archivos no recuperables
16.5 Sufijo de archivos no recuperables
---------------------------------------
Cuando `fix` no puede recuperar por completo un archivo dañado, lo pone en
@ -2104,7 +2087,7 @@ Evite utilizar la extensión `.unrecoverable` para archivos normales y asegúres
de incluir `exclude *.unrecoverable` en su configuración para evitar que dichos
archivos se rastreen en el conjunto de datos de paridad.
16.7 Recuperación con fix parcial
16.6 Recuperación con fix parcial
---------------------------------
Cuando `fix` se restringe mediante `-S, --start` o `-B, --count`,
@ -2126,6 +2109,32 @@ avanzada, típicamente después de que un `fix` normal haya fallado. Si un `fix`
parcial informa de datos no recuperables, elimine o renombre los archivos
afectados antes de intentar otra recuperación, o verifique su contenido manualmente.
16.7 Enlaces duros en NTFS y rutas excluidas
--------------------------------------------
En NTFS, las entradas de directorio almacenan en caché el tamaño del
archivo y las marcas de tiempo de forma independiente para cada enlace
duro. Cuando un archivo se modifica a través de un enlace, las entradas
de directorio de otros enlaces que apuntan al mismo archivo pueden
conservar metadatos obsoletos hasta que se accede a ellos.
SnapRAID detecta y normaliza automáticamente esta condición siempre que
se encuentran al menos dos enlaces duros al mismo archivo durante un
escaneo. Sin embargo, si solo se escanea un enlace duro mientras los
demás están excluidos por filtros o se encuentran fuera de la ruta del
disco de datos, SnapRAID no puede detectar la colisión de inodos y confía
en los metadatos almacenados en caché del único enlace visible.
En consecuencia, las modificaciones realizadas a través de un enlace duro
excluido o externo pueden pasar desapercibidas para SnapRAID hasta que el
sistema operativo actualice los metadatos del enlace incluido (como cuando
se accede al archivo o se abre a través de esa ruta).
Para evitar esta limitación, evite modificar archivos protegidos a través
de enlaces duros que estén excluidos de SnapRAID, o asegúrese de que
todos los enlaces duros a un archivo se incluyan en el escaneo para que
SnapRAID pueda normalizarlos.
17 TRADUCCIóN (TRANSLATION)
===========================

37
doc/snapraid-fr.1
View file

@ -2440,20 +2440,6 @@ devenir visible.
Ne placez pas de points de montage imbriqués ou de montages bind dans les
disques de données lorsque les instantanés du système de fichiers sont
activés.
.SS Liens matériels
SnapRAID identifie un lien matériel comme le fichier d\'origine et représente
les autres liens matériels comme des références à celui\-ci. Le lien sélectionné
comme fichier d\'origine dépend de l\'ordre dans lequel les entrées de
répertoire sont analysées.
.PP
Si cet ordre change, par exemple après le renommage, la restauration de
fichiers ou la recréation de répertoires, \[dq]diff\[dq] peut signaler des
déplacements, mises à jour, ajouts ou suppressions apparents même lorsque
les fichiers liés représentent toujours les mêmes données.
.PP
Cela n\'indique pas une corruption des données, mais les différences
signalées peuvent prêter à confusion et ne pas correspondre directement aux
opérations effectuées sur le système de fichiers.
.SS Modifications de fichiers sur place sans changement d\'horodatage
SnapRAID détecte les modifications de fichiers en comparant la taille des
fichiers et les horodatages de modification (mtime).
@ -2528,6 +2514,29 @@ avancée, généralement après l\'échec d\'un \`fix\` normal. Si un \`fix\` pa
signale des données irrécupérables, supprimez ou renommez les fichiers
concernés avant de tenter une nouvelle récupération, ou vérifiez manuellement
leur contenu.
.SS Liens matériels NTFS et chemins exclus
Sur NTFS, les entrées de répertoire mettent en cache la taille du fichier
et les horodatages indépendamment pour chaque lien matériel. Lorsqu\'un
fichier est modifié via un lien, les entrées de répertoire des autres liens
pointant vers le même fichier peuvent conserver des métadonnées obsolètes
jusqu\'à ce qu\'on y accède.
.PP
SnapRAID détecte et normalise automatiquement cette condition chaque fois
qu\'au moins deux liens matériels vers le même fichier sont rencontrés lors
d\'une analyse. Cependant, si un seul lien matériel est analysé alors que
les autres sont exclus par des filtres ou résident en dehors du chemin du
disque de données, SnapRAID ne peut pas détecter la collision d\'inodes et
s\'appuie sur les métadonnées en cache du seul lien visible.
.PP
Par conséquent, les modifications apportées via un lien matériel exclu ou
externe peuvent passer inaperçues pour SnapRAID jusqu\'à ce que les
métadonnées du lien inclus soient actualisées par le système d\'exploitation
(par exemple lorsque le fichier est accédé ou ouvert via ce chemin).
.PP
Pour éviter cette limitation, évitez de modifier les fichiers protégés
via des liens matériels exclus de SnapRAID, ou assurez\-vous que tous les
liens matériels vers un fichier sont inclus dans l\'analyse afin que
SnapRAID puisse les normaliser.
.SH TRADUCTION (TRANSLATION)
Ce document est une traduction automatique du manuel en anglais.
Veuillez vous référer au manuel en anglais pour la version officielle.

39
doc/snapraid-fr.d
View file

@ -1935,21 +1935,6 @@ Problèmes connus (Known Issues)
disques de données lorsque les instantanés du système de fichiers sont
activés.
Liens matériels
SnapRAID identifie un lien matériel comme le fichier d'origine et représente
les autres liens matériels comme des références à celui-ci. Le lien sélectionné
comme fichier d'origine dépend de l'ordre dans lequel les entrées de
répertoire sont analysées.
Si cet ordre change, par exemple après le renommage, la restauration de
fichiers ou la recréation de répertoires, "diff" peut signaler des
déplacements, mises à jour, ajouts ou suppressions apparents même lorsque
les fichiers liés représentent toujours les mêmes données.
Cela n'indique pas une corruption des données, mais les différences
signalées peuvent prêter à confusion et ne pas correspondre directement aux
opérations effectuées sur le système de fichiers.
Modifications de fichiers sur place sans changement d'horodatage
SnapRAID détecte les modifications de fichiers en comparant la taille des
fichiers et les horodatages de modification (mtime).
@ -2028,6 +2013,30 @@ Problèmes connus (Known Issues)
concernés avant de tenter une nouvelle récupération, ou vérifiez manuellement
leur contenu.
Liens matériels NTFS et chemins exclus
Sur NTFS, les entrées de répertoire mettent en cache la taille du fichier
et les horodatages indépendamment pour chaque lien matériel. Lorsqu'un
fichier est modifié via un lien, les entrées de répertoire des autres liens
pointant vers le même fichier peuvent conserver des métadonnées obsolètes
jusqu'à ce qu'on y accède.
SnapRAID détecte et normalise automatiquement cette condition chaque fois
qu'au moins deux liens matériels vers le même fichier sont rencontrés lors
d'une analyse. Cependant, si un seul lien matériel est analysé alors que
les autres sont exclus par des filtres ou résident en dehors du chemin du
disque de données, SnapRAID ne peut pas détecter la collision d'inodes et
s'appuie sur les métadonnées en cache du seul lien visible.
Par conséquent, les modifications apportées via un lien matériel exclu ou
externe peuvent passer inaperçues pour SnapRAID jusqu'à ce que les
métadonnées du lien inclus soient actualisées par le système d'exploitation
(par exemple lorsque le fichier est accédé ou ouvert via ce chemin).
Pour éviter cette limitation, évitez de modifier les fichiers protégés
via des liens matériels exclus de SnapRAID, ou assurez-vous que tous les
liens matériels vers un fichier sont inclus dans l'analyse afin que
SnapRAID puisse les normaliser.
Traduction (Translation)
Ce document est une traduction automatique du manuel en anglais.
Veuillez vous référer au manuel en anglais pour la version officielle.

51
doc/snapraid-fr.txt
View file

@ -2070,24 +2070,7 @@ Ne placez pas de points de montage imbriqués ou de montages bind dans les
disques de données lorsque les instantanés du système de fichiers sont
activés.
16.3 Liens matériels
--------------------
SnapRAID identifie un lien matériel comme le fichier d'origine et représente
les autres liens matériels comme des références à celui-ci. Le lien sélectionné
comme fichier d'origine dépend de l'ordre dans lequel les entrées de
répertoire sont analysées.
Si cet ordre change, par exemple après le renommage, la restauration de
fichiers ou la recréation de répertoires, "diff" peut signaler des
déplacements, mises à jour, ajouts ou suppressions apparents même lorsque
les fichiers liés représentent toujours les mêmes données.
Cela n'indique pas une corruption des données, mais les différences
signalées peuvent prêter à confusion et ne pas correspondre directement aux
opérations effectuées sur le système de fichiers.
16.4 Modifications de fichiers sur place sans changement d'horodatage
16.3 Modifications de fichiers sur place sans changement d'horodatage
---------------------------------------------------------------------
SnapRAID détecte les modifications de fichiers en comparant la taille des
@ -2102,7 +2085,7 @@ l'horodatage de modification du fichier (par exemple avec l'utilitaire
"touch"). Sinon, la différence ne sera détectée que sous la forme d'une
non-concordance de hachage lors d'un "scrub" ou "check" ultérieur.
16.5 Correspondance de casse non-ASCII sous Windows
16.4 Correspondance de casse non-ASCII sous Windows
---------------------------------------------------
SnapRAID utilise un encodage UTF-8 standard et prévisible sur toutes les
@ -2125,7 +2108,7 @@ Pour éviter les écarts causés par le repliement de casse de Windows, spécifi
toujours la casse exacte de tous les caractères non-ASCII dans les chemins de
configuration et les filtres.
16.6 Suffixe des fichiers irrécupérables
16.5 Suffixe des fichiers irrécupérables
----------------------------------------
Lorsque `fix` ne peut pas récupérer entièrement un fichier endommagé, il le
@ -2149,7 +2132,7 @@ assurez-vous que la règle `exclude *.unrecoverable` est incluse dans votre
configuration afin d'empêcher le suivi de ces fichiers dans le jeu de données
de parité.
16.7 Récupération avec fix partiel
16.6 Récupération avec fix partiel
----------------------------------
Lorsque `fix` est restreint avec `-S, --start` ou `-B, --count`,
@ -2173,6 +2156,32 @@ signale des données irrécupérables, supprimez ou renommez les fichiers
concernés avant de tenter une nouvelle récupération, ou vérifiez manuellement
leur contenu.
16.7 Liens matériels NTFS et chemins exclus
-------------------------------------------
Sur NTFS, les entrées de répertoire mettent en cache la taille du fichier
et les horodatages indépendamment pour chaque lien matériel. Lorsqu'un
fichier est modifié via un lien, les entrées de répertoire des autres liens
pointant vers le même fichier peuvent conserver des métadonnées obsolètes
jusqu'à ce qu'on y accède.
SnapRAID détecte et normalise automatiquement cette condition chaque fois
qu'au moins deux liens matériels vers le même fichier sont rencontrés lors
d'une analyse. Cependant, si un seul lien matériel est analysé alors que
les autres sont exclus par des filtres ou résident en dehors du chemin du
disque de données, SnapRAID ne peut pas détecter la collision d'inodes et
s'appuie sur les métadonnées en cache du seul lien visible.
Par conséquent, les modifications apportées via un lien matériel exclu ou
externe peuvent passer inaperçues pour SnapRAID jusqu'à ce que les
métadonnées du lien inclus soient actualisées par le système d'exploitation
(par exemple lorsque le fichier est accédé ou ouvert via ce chemin).
Pour éviter cette limitation, évitez de modifier les fichiers protégés
via des liens matériels exclus de SnapRAID, ou assurez-vous que tous les
liens matériels vers un fichier sont inclus dans l'analyse afin que
SnapRAID puisse les normaliser.
17 TRADUCTION (TRANSLATION)
===========================

36
doc/snapraid-it.1
View file

@ -2416,19 +2416,6 @@ mount nel filesystem live potrebbe diventare visibile.
.PP
Non inserire punti di mount annidati o bind mount all\'interno dei dischi dati
quando le snapshot del filesystem sono abilitate.
.SS Hard link
SnapRAID identifica un hard link come file originale e rappresenta gli altri
hard link come riferimenti ad esso. Quale link viene selezionato come file
originale dipende dall\'ordine in cui vengono scansionate le voci di directory.
.PP
Se questo ordine cambia, ad esempio dopo che i file vengono rinominati,
ripristinati o le directory vengono ricreate, \[dq]diff\[dq] può segnalare apparenti
spostamenti, aggiornamenti, aggiunte o rimozioni anche quando i file collegati
rappresentano ancora gli stessi dati.
.PP
Ciò non indica corruzione dei dati, ma le differenze segnalate possono
generare confusione e potrebbero non corrispondere direttamente alle
operazioni eseguite sul filesystem.
.SS Modifiche ai file sul posto senza variazione di data/ora
SnapRAID rileva le modifiche ai file confrontando le dimensioni dei file e
i timestamp di modifica (mtime).
@ -2500,6 +2487,29 @@ Le opzioni \`\-S\` e \`\-B\` sono destinate esclusivamente al recupero manuale
avanzato, tipicamente dopo che un normale \`fix\` è fallito. Se un \`fix\`
parziale segnala dati irrecuperabili, rimuovere o rinominare i file interessati
prima di tentare un altro recupero, oppure verificarne manualmente il contenuto.
.SS Hard link NTFS e percorsi esclusi
Su NTFS, le voci di directory memorizzano nella cache la dimensione del
file e i timestamp in modo indipendente per ciascun hard link. Quando un
file viene modificato tramite un link, le voci di directory degli altri link
che puntano allo stesso file possono mantenere metadati obsoleti finché non
vengono consultate.
.PP
SnapRAID rileva e normalizza automaticamente questa condizione ogni volta
che incontra almeno due hard link allo stesso file durante una scansione.
Tuttavia, se viene scansionato un solo hard link mentre gli altri sono
esclusi dai filtri o risiedono all\'esterno del percorso del disco dati,
SnapRAID non può rilevare la collisione di inode e si affida ai metadati
nella cache dell\'unico link visibile.
.PP
Di conseguenza, le modifiche apportate tramite un hard link escluso o
esterno potrebbero non essere notate da SnapRAID finché i metadati del
link incluso non vengono aggiornati dal sistema operativo (ad esempio
quando il file viene consultato o aperto tramite tale percorso).
.PP
Per evitare questa limitazione, evitare di modificare i file protetti
tramite hard link esclusi da SnapRAID, oppure assicurarsi che tutti gli
hard link a un file siano inclusi nella scansione in modo che SnapRAID
possa normalizzarli.
.SH TRADUZIONE (TRANSLATION)
Questo documento è una traduzione automatica del manuale in inglese.
Fare riferimento al manuale in inglese per la versione ufficiale.

38
doc/snapraid-it.d
View file

@ -1900,20 +1900,6 @@ Problemi noti (Known Issues)
Non inserire punti di mount annidati o bind mount all'interno dei dischi dati
quando le snapshot del filesystem sono abilitate.
Hard link
SnapRAID identifica un hard link come file originale e rappresenta gli altri
hard link come riferimenti ad esso. Quale link viene selezionato come file
originale dipende dall'ordine in cui vengono scansionate le voci di directory.
Se questo ordine cambia, ad esempio dopo che i file vengono rinominati,
ripristinati o le directory vengono ricreate, "diff" può segnalare apparenti
spostamenti, aggiornamenti, aggiunte o rimozioni anche quando i file collegati
rappresentano ancora gli stessi dati.
Ciò non indica corruzione dei dati, ma le differenze segnalate possono
generare confusione e potrebbero non corrispondere direttamente alle
operazioni eseguite sul filesystem.
Modifiche ai file sul posto senza variazione di data/ora
SnapRAID rileva le modifiche ai file confrontando le dimensioni dei file e
i timestamp di modifica (mtime).
@ -1989,6 +1975,30 @@ Problemi noti (Known Issues)
parziale segnala dati irrecuperabili, rimuovere o rinominare i file interessati
prima di tentare un altro recupero, oppure verificarne manualmente il contenuto.
Hard link NTFS e percorsi esclusi
Su NTFS, le voci di directory memorizzano nella cache la dimensione del
file e i timestamp in modo indipendente per ciascun hard link. Quando un
file viene modificato tramite un link, le voci di directory degli altri link
che puntano allo stesso file possono mantenere metadati obsoleti finché non
vengono consultate.
SnapRAID rileva e normalizza automaticamente questa condizione ogni volta
che incontra almeno due hard link allo stesso file durante una scansione.
Tuttavia, se viene scansionato un solo hard link mentre gli altri sono
esclusi dai filtri o risiedono all'esterno del percorso del disco dati,
SnapRAID non può rilevare la collisione di inode e si affida ai metadati
nella cache dell'unico link visibile.
Di conseguenza, le modifiche apportate tramite un hard link escluso o
esterno potrebbero non essere notate da SnapRAID finché i metadati del
link incluso non vengono aggiornati dal sistema operativo (ad esempio
quando il file viene consultato o aperto tramite tale percorso).
Per evitare questa limitazione, evitare di modificare i file protetti
tramite hard link esclusi da SnapRAID, oppure assicurarsi che tutti gli
hard link a un file siano inclusi nella scansione in modo che SnapRAID
possa normalizzarli.
Traduzione (Translation)
Questo documento è una traduzione automatica del manuale in inglese.
Fare riferimento al manuale in inglese per la versione ufficiale.

50
doc/snapraid-it.txt
View file

@ -2035,23 +2035,7 @@ mount nel filesystem live potrebbe diventare visibile.
Non inserire punti di mount annidati o bind mount all'interno dei dischi dati
quando le snapshot del filesystem sono abilitate.
16.3 Hard link
--------------
SnapRAID identifica un hard link come file originale e rappresenta gli altri
hard link come riferimenti ad esso. Quale link viene selezionato come file
originale dipende dall'ordine in cui vengono scansionate le voci di directory.
Se questo ordine cambia, ad esempio dopo che i file vengono rinominati,
ripristinati o le directory vengono ricreate, "diff" può segnalare apparenti
spostamenti, aggiornamenti, aggiunte o rimozioni anche quando i file collegati
rappresentano ancora gli stessi dati.
Ciò non indica corruzione dei dati, ma le differenze segnalate possono
generare confusione e potrebbero non corrispondere direttamente alle
operazioni eseguite sul filesystem.
16.4 Modifiche ai file sul posto senza variazione di data/ora
16.3 Modifiche ai file sul posto senza variazione di data/ora
-------------------------------------------------------------
SnapRAID rileva le modifiche ai file confrontando le dimensioni dei file e
@ -2066,7 +2050,7 @@ di modifica del file (ad esempio con l'utilità "touch"). Altrimenti, la
differenza verrà rilevata solo come mancata corrispondenza dell'hash durante
un successivo "scrub" o "check".
16.5 Corrispondenza maiuscole/minuscole non ASCII in Windows
16.4 Corrispondenza maiuscole/minuscole non ASCII in Windows
------------------------------------------------------------
SnapRAID utilizza la codifica UTF-8 standard e prevedibile su tutte le
@ -2090,7 +2074,7 @@ maiuscolo/minuscolo di Windows, specificare sempre l'esatta combinazione di
maiuscole/minuscole per qualsiasi carattere non ASCII nei percorsi di
configurazione e nei filtri.
16.6 Suffisso dei file irrecuperabili
16.5 Suffisso dei file irrecuperabili
-------------------------------------
Quando `fix` non riesce a recuperare completamente un file danneggiato,
@ -2112,7 +2096,7 @@ Evitare di utilizzare l'estensione `.unrecoverable` per i normali file e
assicurarsi che la regola `exclude *.unrecoverable` sia inclusa nella
configurazione per evitare che tali file vengano tracciati nel dataset di parità.
16.7 Recupero con fix parziale
16.6 Recupero con fix parziale
------------------------------
Quando `fix` viene limitato usando `-S, --start` o `-B, --count`,
@ -2134,6 +2118,32 @@ avanzato, tipicamente dopo che un normale `fix` è fallito. Se un `fix`
parziale segnala dati irrecuperabili, rimuovere o rinominare i file interessati
prima di tentare un altro recupero, oppure verificarne manualmente il contenuto.
16.7 Hard link NTFS e percorsi esclusi
--------------------------------------
Su NTFS, le voci di directory memorizzano nella cache la dimensione del
file e i timestamp in modo indipendente per ciascun hard link. Quando un
file viene modificato tramite un link, le voci di directory degli altri link
che puntano allo stesso file possono mantenere metadati obsoleti finché non
vengono consultate.
SnapRAID rileva e normalizza automaticamente questa condizione ogni volta
che incontra almeno due hard link allo stesso file durante una scansione.
Tuttavia, se viene scansionato un solo hard link mentre gli altri sono
esclusi dai filtri o risiedono all'esterno del percorso del disco dati,
SnapRAID non può rilevare la collisione di inode e si affida ai metadati
nella cache dell'unico link visibile.
Di conseguenza, le modifiche apportate tramite un hard link escluso o
esterno potrebbero non essere notate da SnapRAID finché i metadati del
link incluso non vengono aggiornati dal sistema operativo (ad esempio
quando il file viene consultato o aperto tramite tale percorso).
Per evitare questa limitazione, evitare di modificare i file protetti
tramite hard link esclusi da SnapRAID, oppure assicurarsi che tutti gli
hard link a un file siano inclusi nella scansione in modo che SnapRAID
possa normalizzarli.
17 TRADUZIONE (TRANSLATION)
===========================

32
doc/snapraid-ja.1
View file

@ -2173,17 +2173,6 @@ SnapRAIDは警告（WARNING）を報告し、その先をスキャンしませ
.PP
ファイルシステムスナップショットが有効な場合は、データディスク内にネストされた
マウントポイントやバインドマウントを配置しないでください。
.SS ハードリンク
SnapRAIDは、1つのハードリンクを元のファイルとして識別し、他のハードリンクを
それへの参照として表します。どのリンクが元のファイルとして選択されるかは、
ディレクトリエントリがスキャンされる順序によって決まります。
.PP
ファイルの名前変更、復元、またはディレクトリの再作成などによってこの順序が
変化した場合、リンクされたファイルが依然として同じデータを表していても、
\[dq]diff\[dq] が見かけ上の移動、更新、追加、または削除を報告することがあります。
.PP
これはデータの破損を示すものではありませんが、報告される差分は混乱を招く
可能性があり、実行されたファイルシステム操作と直接一致しない場合があります。
.SS タイムスタンプの変更を伴わないインプレースファイル変更
SnapRAIDは、ファイルサイズと変更タイムスタンプ（mtime）を比較することによって
ファイルの変更を検出します。
@ -2248,6 +2237,27 @@ SnapRAID は選択されたブロックのみを処理し、ファイルレベ
のみを目的としています。部分的な \`fix\` で回復不能なデータが報告された場合は、
別の回復を試みる前に対象のファイルを削除または名前変更するか、その内容を手動で
確認してください。
.SS NTFS ハードリンクと除外されたパス
NTFS では、ディレクトリエントリが各ハードリンクのファイルサイズとタイム
スタンプを個別にキャッシュします。ファイルがいずれか1つのリンクを通じて
変更された場合、同じファイルを参照している他のリンクのディレクトリエントリ
は、それらにアクセスされるまで古いメタデータを保持し続けることがあります。
.PP
SnapRAID は、スキャン中に同じファイルへのハードリンクが2つ以上見つかった
場合、この状態を自動的に検出して正規化します。しかし、他のリンクがフィルタ
によって除外されているか、またはデータディスクのパスの外部にあるために
1つのハードリンクのみがスキャンされた場合、SnapRAID は inode の衝突を検出
できず、単一の見えているリンクのキャッシュされたメタデータに依存します。
.PP
その結果、除外されたリンクや外部のハードリンクを通じて加えられた変更は、
対象のファイルがアクセスされたりそのパスを通じて開かれたりして OS により
含まれるリンクのメタデータが更新されるまで、SnapRAID に気付かれない可能性
があります。
.PP
この制限を回避するには、SnapRAID から除外されているハードリンクを通じて
保護対象のファイルを変更しないようにするか、SnapRAID が正常に正規化
できるように、ファイルへのすべてのハードリンクがスキャンに含まれるように
してください。
.SH 翻訳 (TRANSLATION)
この文書は英語版マニュアルの自動翻訳です。
正確な記述については英語版マニュアルを参照してください。

34
doc/snapraid-ja.d
View file

@ -1671,18 +1671,6 @@ Name{number}
ファイルシステムスナップショットが有効な場合は、データディスク内にネストされた
マウントポイントやバインドマウントを配置しないでください。
ハードリンク
SnapRAIDは、1つのハードリンクを元のファイルとして識別し、他のハードリンクを
それへの参照として表します。どのリンクが元のファイルとして選択されるかは、
ディレクトリエントリがスキャンされる順序によって決まります。
ファイルの名前変更、復元、またはディレクトリの再作成などによってこの順序が
変化した場合、リンクされたファイルが依然として同じデータを表していても、
"diff" が見かけ上の移動、更新、追加、または削除を報告することがあります。
これはデータの破損を示すものではありませんが、報告される差分は混乱を招く
可能性があり、実行されたファイルシステム操作と直接一致しない場合があります。
タイムスタンプの変更を伴わないインプレースファイル変更
SnapRAIDは、ファイルサイズと変更タイムスタンプ（mtime）を比較することによって
ファイルの変更を検出します。
@ -1751,6 +1739,28 @@ Name{number}
別の回復を試みる前に対象のファイルを削除または名前変更するか、その内容を手動で
確認してください。
NTFS ハードリンクと除外されたパス
NTFS では、ディレクトリエントリが各ハードリンクのファイルサイズとタイム
スタンプを個別にキャッシュします。ファイルがいずれか1つのリンクを通じて
変更された場合、同じファイルを参照している他のリンクのディレクトリエントリ
は、それらにアクセスされるまで古いメタデータを保持し続けることがあります。
SnapRAID は、スキャン中に同じファイルへのハードリンクが2つ以上見つかった
場合、この状態を自動的に検出して正規化します。しかし、他のリンクがフィルタ
によって除外されているか、またはデータディスクのパスの外部にあるために
1つのハードリンクのみがスキャンされた場合、SnapRAID は inode の衝突を検出
できず、単一の見えているリンクのキャッシュされたメタデータに依存します。
その結果、除外されたリンクや外部のハードリンクを通じて加えられた変更は、
対象のファイルがアクセスされたりそのパスを通じて開かれたりして OS により
含まれるリンクのメタデータが更新されるまで、SnapRAID に気付かれない可能性
があります。
この制限を回避するには、SnapRAID から除外されているハードリンクを通じて
保護対象のファイルを変更しないようにするか、SnapRAID が正常に正規化
できるように、ファイルへのすべてのハードリンクがスキャンに含まれるように
してください。
翻訳 (Translation)
この文書は英語版マニュアルの自動翻訳です。
正確な記述については英語版マニュアルを参照してください。

46
doc/snapraid-ja.txt
View file

@ -1806,21 +1806,7 @@ SnapRAIDは警告（WARNING）を報告し、その先をスキャンしませ
ファイルシステムスナップショットが有効な場合は、データディスク内にネストされた
マウントポイントやバインドマウントを配置しないでください。
16.3 ハードリンク
-----------
SnapRAIDは、1つのハードリンクを元のファイルとして識別し、他のハードリンクを
それへの参照として表します。どのリンクが元のファイルとして選択されるかは、
ディレクトリエントリがスキャンされる順序によって決まります。
ファイルの名前変更、復元、またはディレクトリの再作成などによってこの順序が
変化した場合、リンクされたファイルが依然として同じデータを表していても、
"diff" が見かけ上の移動、更新、追加、または削除を報告することがあります。
これはデータの破損を示すものではありませんが、報告される差分は混乱を招く
可能性があり、実行されたファイルシステム操作と直接一致しない場合があります。
16.4 タイムスタンプの変更を伴わないインプレースファイル変更
16.3 タイムスタンプの変更を伴わないインプレースファイル変更
--------------------------------
SnapRAIDは、ファイルサイズと変更タイムスタンプ（mtime）を比較することによって
@ -1835,7 +1821,7 @@ SnapRAIDにそのような変更を確実に認識させるには、ファイル
場合、その差分は後続の "scrub" または "check" 中のハッシュ不一致としてのみ
検出されます。
16.5 Windowsにおける非ASCII文字の大文字・小文字の一致
16.4 Windowsにおける非ASCII文字の大文字・小文字の一致
-----------------------------------
SnapRAIDはすべてのプラットフォームで標準的で予測可能なUTF-8エンコーディング
@ -1854,7 +1840,7 @@ Unicodeファイル名全体で大文字・小文字の不区別を強制する
ディングに起因する不一致を防ぐため、設定パスおよびフィルター内の非ASCII文字には
常に正確な大文字・小文字を指定してください。
16.6 回復不能ファイルのサフィックス
16.5 回復不能ファイルのサフィックス
--------------------
`fix` が破損したファイルを完全に回復できない場合、その名前に `.unrecoverable`
@ -1874,7 +1860,7 @@ SnapRAID はファイル名のみに基づいて隔離ファイルを識別す
パリティデータセットで追跡されないように設定に `exclude *.unrecoverable` が含まれている
ことを確認してください。
16.7 部分的な fix による回復
16.6 部分的な fix による回復
-------------------
`fix` を `-S, --start` または `-B, --count` で制限した場合、
@ -1896,6 +1882,30 @@ SnapRAID は選択されたブロックのみを処理し、ファイルレベ
別の回復を試みる前に対象のファイルを削除または名前変更するか、その内容を手動で
確認してください。
16.7 NTFS ハードリンクと除外されたパス
------------------------
NTFS では、ディレクトリエントリが各ハードリンクのファイルサイズとタイム
スタンプを個別にキャッシュします。ファイルがいずれか1つのリンクを通じて
変更された場合、同じファイルを参照している他のリンクのディレクトリエントリ
は、それらにアクセスされるまで古いメタデータを保持し続けることがあります。
SnapRAID は、スキャン中に同じファイルへのハードリンクが2つ以上見つかった
場合、この状態を自動的に検出して正規化します。しかし、他のリンクがフィルタ
によって除外されているか、またはデータディスクのパスの外部にあるために
1つのハードリンクのみがスキャンされた場合、SnapRAID は inode の衝突を検出
できず、単一の見えているリンクのキャッシュされたメタデータに依存します。
その結果、除外されたリンクや外部のハードリンクを通じて加えられた変更は、
対象のファイルがアクセスされたりそのパスを通じて開かれたりして OS により
含まれるリンクのメタデータが更新されるまで、SnapRAID に気付かれない可能性
があります。
この制限を回避するには、SnapRAID から除外されているハードリンクを通じて
保護対象のファイルを変更しないようにするか、SnapRAID が正常に正規化
できるように、ファイルへのすべてのハードリンクがスキャンに含まれるように
してください。
17 翻訳 (TRANSLATION)
===================

30
doc/snapraid-ko.1
View file

@ -2220,17 +2220,6 @@ SnapRAID는 데이터 디스크를 스캔하는 동안 파일 시스템, 마운
.PP
파일 시스템 스냅샷이 활성화된 경우 데이터 디스크 내에 중첩된 마운트 지점이나
바인드 마운트를 배치하지 마십시오.
.SS 하드 링크
SnapRAID는 하나의 하드 링크를 원본 파일로 식별하고 다른 하드 링크를 이에 대한
참조로 표시합니다. 어떤 링크가 원본 파일로 선택되는지는 디렉터리 항목이 스캔되는
순서에 따라 달라집니다.
.PP
파일 이름 변경, 복원 또는 디렉터리 재생성 등으로 인해 이 순서가 변경되면,
하드 링크된 파일이 여전히 동일한 데이터를 나타내더라도 \[dq]diff\[dq]에서 겉보기 이동,
업데이트, 추가 또는 제거를 보고할 수 있습니다.
.PP
이는 데이터 손상을 의미하지 않지만, 보고된 차이점이 혼란을 줄 수 있으며 수행된
파일 시스템 작업과 직접 일치하지 않을 수 있습니다.
.SS 타임스탬프 변경 없는 인플레이스 파일 수정
SnapRAID는 파일 크기와 수정 타임스탬프(mtime)를 비교하여 파일 수정을 감지합니다.
.PP
@ -2290,6 +2279,25 @@ SnapRAID는 선택된 블록에서만 작동하며 파일 수준의 완료 처
위한 것입니다. 부분 \`fix\`에서 복구할 수 없는 데이터가 보고되면 다른 복구를
시도하기 전에 영향을 받는 파일을 제거하거나 이름을 바꾸거나 해당 내용을
수동으로 확인하십시오.
.SS NTFS 하드 링크 및 제외된 경로
NTFS에서는 디렉터리 항목이 각 하드 링크의 파일 크기와 타임스탬프를
독립적으로 캐시합니다. 한 링크를 통해 파일이 수정되면 동일한 파일을
가리키는 다른 링크의 디렉터리 항목은 액세스될 때까지 오래된 메타데이터를
유지할 수 있습니다.
.PP
SnapRAID는 스캔 중에 동일한 파일에 대한 하드 링크를 2개 이상 발견하면
이러한 상태를 자동으로 감지하고 정규화합니다. 그러나 다른 링크가 필터에
의해 제외되었거나 데이터 디스크 경로 외부에 있어 하나의 하드 링크만
스캔되는 경우, SnapRAID는 inode 충돌을 감지할 수 없으며 표시되는 유일한
링크의 캐시된 메타데이터에 의존합니다.
.PP
결과적으로 제외되었거나 외부 하드 링크를 통해 변경된 사항은 해당 경로를
통해 파일에 액세스하거나 열어 운영 체제에서 포함된 링크의 메타데이터를
새로 고칠 때까지 SnapRAID에서 감지되지 않을 수 있습니다.
.PP
이러한 제한을 방지하려면 SnapRAID에서 제외된 하드 링크를 통해 보호된
파일을 수정하지 않거나, SnapRAID가 이를 정규화할 수 있도록 파일의 모든
하드 링크가 스캔에 포함되도록 하십시오.
.SH 번역 (TRANSLATION)
이 문서는 영어 매뉴얼의 자동 번역본입니다.
공식 버전은 영어 매뉴얼을 참조하십시오.

32
doc/snapraid-ko.d
View file

@ -1718,18 +1718,6 @@ Name{number}
파일 시스템 스냅샷이 활성화된 경우 데이터 디스크 내에 중첩된 마운트 지점이나
바인드 마운트를 배치하지 마십시오.
하드 링크
SnapRAID는 하나의 하드 링크를 원본 파일로 식별하고 다른 하드 링크를 이에 대한
참조로 표시합니다. 어떤 링크가 원본 파일로 선택되는지는 디렉터리 항목이 스캔되는
순서에 따라 달라집니다.
파일 이름 변경, 복원 또는 디렉터리 재생성 등으로 인해 이 순서가 변경되면,
하드 링크된 파일이 여전히 동일한 데이터를 나타내더라도 "diff"에서 겉보기 이동,
업데이트, 추가 또는 제거를 보고할 수 있습니다.
이는 데이터 손상을 의미하지 않지만, 보고된 차이점이 혼란을 줄 수 있으며 수행된
파일 시스템 작업과 직접 일치하지 않을 수 있습니다.
타임스탬프 변경 없는 인플레이스 파일 수정
SnapRAID는 파일 크기와 수정 타임스탬프(mtime)를 비교하여 파일 수정을 감지합니다.
@ -1793,6 +1781,26 @@ Name{number}
시도하기 전에 영향을 받는 파일을 제거하거나 이름을 바꾸거나 해당 내용을
수동으로 확인하십시오.
NTFS 하드 링크 및 제외된 경로
NTFS에서는 디렉터리 항목이 각 하드 링크의 파일 크기와 타임스탬프를
독립적으로 캐시합니다. 한 링크를 통해 파일이 수정되면 동일한 파일을
가리키는 다른 링크의 디렉터리 항목은 액세스될 때까지 오래된 메타데이터를
유지할 수 있습니다.
SnapRAID는 스캔 중에 동일한 파일에 대한 하드 링크를 2개 이상 발견하면
이러한 상태를 자동으로 감지하고 정규화합니다. 그러나 다른 링크가 필터에
의해 제외되었거나 데이터 디스크 경로 외부에 있어 하나의 하드 링크만
스캔되는 경우, SnapRAID는 inode 충돌을 감지할 수 없으며 표시되는 유일한
링크의 캐시된 메타데이터에 의존합니다.
결과적으로 제외되었거나 외부 하드 링크를 통해 변경된 사항은 해당 경로를
통해 파일에 액세스하거나 열어 운영 체제에서 포함된 링크의 메타데이터를
새로 고칠 때까지 SnapRAID에서 감지되지 않을 수 있습니다.
이러한 제한을 방지하려면 SnapRAID에서 제외된 하드 링크를 통해 보호된
파일을 수정하지 않거나, SnapRAID가 이를 정규화할 수 있도록 파일의 모든
하드 링크가 스캔에 포함되도록 하십시오.
번역 (Translation)
이 문서는 영어 매뉴얼의 자동 번역본입니다.
공식 버전은 영어 매뉴얼을 참조하십시오.

44
doc/snapraid-ko.txt
View file

@ -1853,21 +1853,7 @@ SnapRAID는 데이터 디스크를 스캔하는 동안 파일 시스템, 마운
파일 시스템 스냅샷이 활성화된 경우 데이터 디스크 내에 중첩된 마운트 지점이나
바인드 마운트를 배치하지 마십시오.
16.3 하드 링크
----------
SnapRAID는 하나의 하드 링크를 원본 파일로 식별하고 다른 하드 링크를 이에 대한
참조로 표시합니다. 어떤 링크가 원본 파일로 선택되는지는 디렉터리 항목이 스캔되는
순서에 따라 달라집니다.
파일 이름 변경, 복원 또는 디렉터리 재생성 등으로 인해 이 순서가 변경되면,
하드 링크된 파일이 여전히 동일한 데이터를 나타내더라도 "diff"에서 겉보기 이동,
업데이트, 추가 또는 제거를 보고할 수 있습니다.
이는 데이터 손상을 의미하지 않지만, 보고된 차이점이 혼란을 줄 수 있으며 수행된
파일 시스템 작업과 직접 일치하지 않을 수 있습니다.
16.4 타임스탬프 변경 없는 인플레이스 파일 수정
16.3 타임스탬프 변경 없는 인플레이스 파일 수정
----------------------------
SnapRAID는 파일 크기와 수정 타임스탬프(mtime)를 비교하여 파일 수정을 감지합니다.
@ -1880,7 +1866,7 @@ SnapRAID가 이러한 변경 사항을 인식하도록 하려면 파일의 수
업데이트하십시오(예: "touch" 유틸리티 사용). 그렇지 않으면 이 차이점은 이후의
"scrub" 또는 "check" 중에 해시 불일치로만 감지됩니다.
16.5 Windows 비ASCII 대소문자 일치
16.4 Windows 비ASCII 대소문자 일치
---------------------------
SnapRAID는 모든 플랫폼에서 표준적이고 예측 가능한 UTF-8 인코딩을 사용하며,
@ -1899,7 +1885,7 @@ Windows 파일 시스템은 임의의 시스템 종속 폴딩 테이블을 통
방지하려면 구성 경로 및 필터의 비ASCII 문자에 대해 항상 정확한 대소문자를
지정하십시오.
16.6 복구할 수 없는 파일 접미사
16.5 복구할 수 없는 파일 접미사
--------------------
`fix`가 손상된 파일을 완전히 복구할 수 없는 경우, 이름에 `.unrecoverable` 확장자를
@ -1918,7 +1904,7 @@ SnapRAID는 오직 파일 이름으로만 격리 파일을 식별하므로, 우
일반 파일에는 `.unrecoverable` 확장자를 사용하지 마시고, 해당 파일이 패리티 데이터셋에서
추적되지 않도록 구성에 `exclude *.unrecoverable`이 포함되어 있는지 확인하십시오.
16.7 부분 fix 복구
16.6 부분 fix 복구
--------------
`fix`가 `-S, --start` 또는 `-B, --count`를 사용하여 제한되면,
@ -1938,6 +1924,28 @@ SnapRAID는 선택된 블록에서만 작동하며 파일 수준의 완료 처
시도하기 전에 영향을 받는 파일을 제거하거나 이름을 바꾸거나 해당 내용을
수동으로 확인하십시오.
16.7 NTFS 하드 링크 및 제외된 경로
------------------------
NTFS에서는 디렉터리 항목이 각 하드 링크의 파일 크기와 타임스탬프를
독립적으로 캐시합니다. 한 링크를 통해 파일이 수정되면 동일한 파일을
가리키는 다른 링크의 디렉터리 항목은 액세스될 때까지 오래된 메타데이터를
유지할 수 있습니다.
SnapRAID는 스캔 중에 동일한 파일에 대한 하드 링크를 2개 이상 발견하면
이러한 상태를 자동으로 감지하고 정규화합니다. 그러나 다른 링크가 필터에
의해 제외되었거나 데이터 디스크 경로 외부에 있어 하나의 하드 링크만
스캔되는 경우, SnapRAID는 inode 충돌을 감지할 수 없으며 표시되는 유일한
링크의 캐시된 메타데이터에 의존합니다.
결과적으로 제외되었거나 외부 하드 링크를 통해 변경된 사항은 해당 경로를
통해 파일에 액세스하거나 열어 운영 체제에서 포함된 링크의 메타데이터를
새로 고칠 때까지 SnapRAID에서 감지되지 않을 수 있습니다.
이러한 제한을 방지하려면 SnapRAID에서 제외된 하드 링크를 통해 보호된
파일을 수정하지 않거나, SnapRAID가 이를 정규화할 수 있도록 파일의 모든
하드 링크가 스캔에 포함되도록 하십시오.
17 번역 (TRANSLATION)
===================

37
doc/snapraid-pl.1
View file

@ -2304,19 +2304,6 @@ systemie plików może stać się widoczny.
.PP
Nie umieszczaj zagnieżdżonych punktów montowania ani montowań bind wewnątrz
dysków z danymi, gdy migawki systemu plików są włączone.
.SS Twarde dowiązania (Hard links)
SnapRAID identyfikuje jedno twarde dowiązanie jako plik oryginalny, a
pozostałe twarde dowiązania reprezentuje jako odwołania do niego. To, które
dowiązanie zostanie wybrane jako plik oryginalny, zależy od kolejności
skanowania wpisów w katalogu.
.PP
Jeśli ta kolejność ulegnie zmianie, na przykład po zmianie nazwy,
przywróceniu plików lub ponownym utworzeniu katalogów, polecenie \[dq]diff\[dq]
może zgłaszać pozorne przeniesienia, aktualizacje, dodania lub usunięcia,
nawet jeśli dowiązane pliki nadal reprezentują te same dane.
.PP
Nie oznacza to uszkodzenia danych, ale zgłaszane różnice mogą być mylące i
mogą nie odpowiadać bezpośrednio operacjom wykonanym w systemie plików.
.SS Modyfikacje plików w miejscu bez zmiany znacznika czasu
SnapRAID wykrywa modyfikacje plików, porównując rozmiary plików oraz
znaczniki czasu modyfikacji (mtime).
@ -2388,6 +2375,30 @@ ręcznego, zazwyczaj po niepowodzeniu normalnego \`fix\`. Jeśli częściowy \`f
zgłosi dane niemożliwe do odzyskania, przed podjęciem kolejnej próby odzyskiwania
należy usunąć lub zmienić nazwę plików, których to dotyczy, albo ręcznie zweryfikować
ich zawartość.
.SS Twarde dowiązania NTFS i wykluczone ścieżki
W systemie plików NTFS wpisy katalogowe niezależnie buforują rozmiar pliku
i znaczniki czasu dla każdego twardego dowiązania. Gdy plik zostanie
zmodyfikowany za pośrednictwem jednego dowiązania, wpisy katalogowe innych
dowiązań wskazujących ten sam plik mogą zachowywać nieaktualne metadane
do momentu uzyskania do nich dostępu.
.PP
SnapRAID automatycznie wykrywa i normalizuje ten stan, gdy podczas skanowania
napotka co najmniej dwa twarde dowiązania do tego samego pliku. Jeśli jednak
zeskanowane zostanie tylko jedno twarde dowiązanie, podczas gdy pozostałe są
wykluczone przez filtry lub znajdują się poza ścieżką dysku danych, SnapRAID
nie może wykryć kolizji i\-węzłów (inode) i polega na buforowanych metadanych
jedynego widocznego dowiązania.
.PP
W konsekwencji modyfikacje dokonane za pośrednictwem wykluczonego lub
zewnętrznego twardego dowiązania mogą pozostać niezauważone przez SnapRAID,
dopóki metadane uwzględnionego dowiązania nie zostaną odświeżone przez system
operacyjny (na przykład po uzyskaniu dostępu do pliku lub otwarciu go
przez tę ścieżkę).
.PP
Aby uniknąć tego ograniczenia, należy unikać modyfikowania chronionych plików
za pośrednictwem twardych dowiązań wykluczonych ze SnapRAID lub upewnić się,
że wszystkie twarde dowiązania do danego pliku są uwzględnione w skanowaniu,
aby SnapRAID mógł je znormalizować.
.SH TłUMACZENIE (TRANSLATION)
Ten dokument jest automatycznym tłumaczeniem angielskiej instrukcji.
Wersję oficjalną stanowi oryginalny podręcznik w języku angielskim.

39
doc/snapraid-pl.d
View file

@ -1802,20 +1802,6 @@ Znane problemy (Known Issues)
Nie umieszczaj zagnieżdżonych punktów montowania ani montowań bind wewnątrz
dysków z danymi, gdy migawki systemu plików są włączone.
Twarde dowiązania (Hard links)
SnapRAID identyfikuje jedno twarde dowiązanie jako plik oryginalny, a
pozostałe twarde dowiązania reprezentuje jako odwołania do niego. To, które
dowiązanie zostanie wybrane jako plik oryginalny, zależy od kolejności
skanowania wpisów w katalogu.
Jeśli ta kolejność ulegnie zmianie, na przykład po zmianie nazwy,
przywróceniu plików lub ponownym utworzeniu katalogów, polecenie "diff"
może zgłaszać pozorne przeniesienia, aktualizacje, dodania lub usunięcia,
nawet jeśli dowiązane pliki nadal reprezentują te same dane.
Nie oznacza to uszkodzenia danych, ale zgłaszane różnice mogą być mylące i
mogą nie odpowiadać bezpośrednio operacjom wykonanym w systemie plików.
Modyfikacje plików w miejscu bez zmiany znacznika czasu
SnapRAID wykrywa modyfikacje plików, porównując rozmiary plików oraz
znaczniki czasu modyfikacji (mtime).
@ -1891,6 +1877,31 @@ Znane problemy (Known Issues)
należy usunąć lub zmienić nazwę plików, których to dotyczy, albo ręcznie zweryfikować
ich zawartość.
Twarde dowiązania NTFS i wykluczone ścieżki
W systemie plików NTFS wpisy katalogowe niezależnie buforują rozmiar pliku
i znaczniki czasu dla każdego twardego dowiązania. Gdy plik zostanie
zmodyfikowany za pośrednictwem jednego dowiązania, wpisy katalogowe innych
dowiązań wskazujących ten sam plik mogą zachowywać nieaktualne metadane
do momentu uzyskania do nich dostępu.
SnapRAID automatycznie wykrywa i normalizuje ten stan, gdy podczas skanowania
napotka co najmniej dwa twarde dowiązania do tego samego pliku. Jeśli jednak
zeskanowane zostanie tylko jedno twarde dowiązanie, podczas gdy pozostałe są
wykluczone przez filtry lub znajdują się poza ścieżką dysku danych, SnapRAID
nie może wykryć kolizji i-węzłów (inode) i polega na buforowanych metadanych
jedynego widocznego dowiązania.
W konsekwencji modyfikacje dokonane za pośrednictwem wykluczonego lub
zewnętrznego twardego dowiązania mogą pozostać niezauważone przez SnapRAID,
dopóki metadane uwzględnionego dowiązania nie zostaną odświeżone przez system
operacyjny (na przykład po uzyskaniu dostępu do pliku lub otwarciu go
przez tę ścieżkę).
Aby uniknąć tego ograniczenia, należy unikać modyfikowania chronionych plików
za pośrednictwem twardych dowiązań wykluczonych ze SnapRAID lub upewnić się,
że wszystkie twarde dowiązania do danego pliku są uwzględnione w skanowaniu,
aby SnapRAID mógł je znormalizować.
Tłumaczenie (Translation)
Ten dokument jest automatycznym tłumaczeniem angielskiej instrukcji.
Wersję oficjalną stanowi oryginalny podręcznik w języku angielskim.

51
doc/snapraid-pl.txt
View file

@ -1937,23 +1937,7 @@ systemie plików może stać się widoczny.
Nie umieszczaj zagnieżdżonych punktów montowania ani montowań bind wewnątrz
dysków z danymi, gdy migawki systemu plików są włączone.
16.3 Twarde dowiązania (Hard links)
-----------------------------------
SnapRAID identyfikuje jedno twarde dowiązanie jako plik oryginalny, a
pozostałe twarde dowiązania reprezentuje jako odwołania do niego. To, które
dowiązanie zostanie wybrane jako plik oryginalny, zależy od kolejności
skanowania wpisów w katalogu.
Jeśli ta kolejność ulegnie zmianie, na przykład po zmianie nazwy,
przywróceniu plików lub ponownym utworzeniu katalogów, polecenie "diff"
może zgłaszać pozorne przeniesienia, aktualizacje, dodania lub usunięcia,
nawet jeśli dowiązane pliki nadal reprezentują te same dane.
Nie oznacza to uszkodzenia danych, ale zgłaszane różnice mogą być mylące i
mogą nie odpowiadać bezpośrednio operacjom wykonanym w systemie plików.
16.4 Modyfikacje plików w miejscu bez zmiany znacznika czasu
16.3 Modyfikacje plików w miejscu bez zmiany znacznika czasu
------------------------------------------------------------
SnapRAID wykrywa modyfikacje plików, porównując rozmiary plików oraz
@ -1968,7 +1952,7 @@ pliku (na przykład za pomocą narzędzia "touch"). W przeciwnym razie różnica
zostanie wykryta dopiero jako niezgodność skrótu podczas kolejnego "scrub"
lub "check".
16.5 Dopasowywanie wielkości liter znaków spoza ASCII w systemie Windows
16.4 Dopasowywanie wielkości liter znaków spoza ASCII w systemie Windows
------------------------------------------------------------------------
SnapRAID używa standardowego, przewidywalnego kodowania UTF-8 na wszystkich
@ -1991,7 +1975,7 @@ liter. Aby zapobiec rozbieżnościom wynikającym ze składania znaków przez
Windows, zawsze podawaj dokładną wielkość liter w przypadku znaków spoza ASCII
w ścieżkach konfiguracyjnych i filtrach.
16.6 Sufiks plików niemożliwych do odzyskania
16.5 Sufiks plików niemożliwych do odzyskania
---------------------------------------------
Gdy `fix` nie może w pełni odzyskać uszkodzonego pliku, poddaje go kwarantannie,
@ -2013,7 +1997,7 @@ Unikaj używania rozszerzenia `.unrecoverable` dla zwykłych plików i upewnij s
że w konfiguracji uwzględniono regułę `exclude *.unrecoverable`, aby zapobiec
śledzeniu takich plików w zbiorze danych parzystości.
16.7 Odzyskiwanie za pomocą częściowego fix
16.6 Odzyskiwanie za pomocą częściowego fix
-------------------------------------------
Gdy polecenie `fix` jest ograniczone za pomocą `-S, --start` lub `-B, --count`,
@ -2036,6 +2020,33 @@ zgłosi dane niemożliwe do odzyskania, przed podjęciem kolejnej próby odzyski
należy usunąć lub zmienić nazwę plików, których to dotyczy, albo ręcznie zweryfikować
ich zawartość.
16.7 Twarde dowiązania NTFS i wykluczone ścieżki
------------------------------------------------
W systemie plików NTFS wpisy katalogowe niezależnie buforują rozmiar pliku
i znaczniki czasu dla każdego twardego dowiązania. Gdy plik zostanie
zmodyfikowany za pośrednictwem jednego dowiązania, wpisy katalogowe innych
dowiązań wskazujących ten sam plik mogą zachowywać nieaktualne metadane
do momentu uzyskania do nich dostępu.
SnapRAID automatycznie wykrywa i normalizuje ten stan, gdy podczas skanowania
napotka co najmniej dwa twarde dowiązania do tego samego pliku. Jeśli jednak
zeskanowane zostanie tylko jedno twarde dowiązanie, podczas gdy pozostałe są
wykluczone przez filtry lub znajdują się poza ścieżką dysku danych, SnapRAID
nie może wykryć kolizji i-węzłów (inode) i polega na buforowanych metadanych
jedynego widocznego dowiązania.
W konsekwencji modyfikacje dokonane za pośrednictwem wykluczonego lub
zewnętrznego twardego dowiązania mogą pozostać niezauważone przez SnapRAID,
dopóki metadane uwzględnionego dowiązania nie zostaną odświeżone przez system
operacyjny (na przykład po uzyskaniu dostępu do pliku lub otwarciu go
przez tę ścieżkę).
Aby uniknąć tego ograniczenia, należy unikać modyfikowania chronionych plików
za pośrednictwem twardych dowiązań wykluczonych ze SnapRAID lub upewnić się,
że wszystkie twarde dowiązania do danego pliku są uwzględnione w skanowaniu,
aby SnapRAID mógł je znormalizować.
17 TłUMACZENIE (TRANSLATION)
============================

37
doc/snapraid-pt.1
View file

@ -2341,20 +2341,6 @@ sistema de arquivos ativo pode se tornar visível.
.PP
Não coloque pontos de montagem aninhados ou montagens bind dentro de discos
de dados quando os instantâneos do sistema de arquivos estiverem ativados.
.SS Links físicos (Hard links)
O SnapRAID identifica um link físico como o arquivo original e representa
os outros links físicos como referências a ele. Qual link é selecionado
como o arquivo original depende da ordem em que as entradas do diretório
são verificadas.
.PP
Se essa ordem mudar, por exemplo, após arquivos serem renomeados,
restaurados ou diretórios serem recriados, o \[dq]diff\[dq] poderá relatar aparentes
movimentações, atualizações, adições ou remoções, mesmo quando os arquivos
vinculados ainda representarem os mesmos dados.
.PP
Isso não indica corrupção de dados, mas as diferenças relatadas podem ser
confusas e podem não corresponder diretamente às operações executadas no
sistema de arquivos.
.SS Modificações de arquivo no local sem alteração de data/hora
O SnapRAID detecta modificações em arquivos comparando tamanhos de arquivo e
carimbos de data/hora de modificação (mtime).
@ -2425,6 +2411,29 @@ As opções \`\-S\` e \`\-B\` destinam\-se apenas à recuperação manual avanç
normalmente após a falha de um \`fix\` normal. Se um \`fix\` parcial relatar
dados irrecuperáveis, remova ou renomeie os arquivos afetados antes de tentar
outra recuperação, ou verifique manualmente seu conteúdo.
.SS Links físicos no NTFS e caminhos excluídos
No NTFS, as entradas de diretório armazenam em cache o tamanho do arquivo
e os registros de data/hora de forma independente para cada link físico.
Quando um arquivo é modificado por meio de um link, as entradas de diretório
de outros links que apontam para o mesmo arquivo podem reter metadados
obsoletos até que sejam acessadas.
.PP
O SnapRAID detecta e normaliza automaticamente essa condição sempre que
pelo menos dois links físicos para o mesmo arquivo são encontrados durante
uma verificação. No entanto, se apenas um link físico for verificado
enquanto os outros forem excluídos por filtros ou residirem fora do caminho
do disco de dados, o SnapRAID não conseguirá detectar a colisão de inodes e
dependerá dos metadados em cache do único link visível.
.PP
Consequentemente, modificações feitas por meio de um link físico excluído
ou externo podem passar despercebidas pelo SnapRAID até que os metadados do
link incluído sejam atualizados pelo sistema operacional (como quando o
arquivo é acessado ou aberto por meio desse caminho).
.PP
Para evitar essa limitação, evite modificar arquivos protegidos por meio
de links físicos excluídos do SnapRAID, ou certifique\-se de que todos os
links físicos de um arquivo sejam incluídos na verificação para que o
SnapRAID possa normalizá\-los.
.SH TRADUçãO (TRANSLATION)
Este documento é uma tradução automática do manual em inglês.
Consulte o manual em inglês para a versão oficial.

39
doc/snapraid-pt.d
View file

@ -1839,21 +1839,6 @@ Problemas Conhecidos (Known Issues)
Não coloque pontos de montagem aninhados ou montagens bind dentro de discos
de dados quando os instantâneos do sistema de arquivos estiverem ativados.
Links físicos (Hard links)
O SnapRAID identifica um link físico como o arquivo original e representa
os outros links físicos como referências a ele. Qual link é selecionado
como o arquivo original depende da ordem em que as entradas do diretório
são verificadas.
Se essa ordem mudar, por exemplo, após arquivos serem renomeados,
restaurados ou diretórios serem recriados, o "diff" poderá relatar aparentes
movimentações, atualizações, adições ou remoções, mesmo quando os arquivos
vinculados ainda representarem os mesmos dados.
Isso não indica corrupção de dados, mas as diferenças relatadas podem ser
confusas e podem não corresponder diretamente às operações executadas no
sistema de arquivos.
Modificações de arquivo no local sem alteração de data/hora
O SnapRAID detecta modificações em arquivos comparando tamanhos de arquivo e
carimbos de data/hora de modificação (mtime).
@ -1928,6 +1913,30 @@ Problemas Conhecidos (Known Issues)
dados irrecuperáveis, remova ou renomeie os arquivos afetados antes de tentar
outra recuperação, ou verifique manualmente seu conteúdo.
Links físicos no NTFS e caminhos excluídos
No NTFS, as entradas de diretório armazenam em cache o tamanho do arquivo
e os registros de data/hora de forma independente para cada link físico.
Quando um arquivo é modificado por meio de um link, as entradas de diretório
de outros links que apontam para o mesmo arquivo podem reter metadados
obsoletos até que sejam acessadas.
O SnapRAID detecta e normaliza automaticamente essa condição sempre que
pelo menos dois links físicos para o mesmo arquivo são encontrados durante
uma verificação. No entanto, se apenas um link físico for verificado
enquanto os outros forem excluídos por filtros ou residirem fora do caminho
do disco de dados, o SnapRAID não conseguirá detectar a colisão de inodes e
dependerá dos metadados em cache do único link visível.
Consequentemente, modificações feitas por meio de um link físico excluído
ou externo podem passar despercebidas pelo SnapRAID até que os metadados do
link incluído sejam atualizados pelo sistema operacional (como quando o
arquivo é acessado ou aberto por meio desse caminho).
Para evitar essa limitação, evite modificar arquivos protegidos por meio
de links físicos excluídos do SnapRAID, ou certifique-se de que todos os
links físicos de um arquivo sejam incluídos na verificação para que o
SnapRAID possa normalizá-los.
Tradução (Translation)
Este documento é uma tradução automática do manual em inglês.
Consulte o manual em inglês para a versão oficial.

51
doc/snapraid-pt.txt
View file

@ -1974,24 +1974,7 @@ sistema de arquivos ativo pode se tornar visível.
Não coloque pontos de montagem aninhados ou montagens bind dentro de discos
de dados quando os instantâneos do sistema de arquivos estiverem ativados.
16.3 Links físicos (Hard links)
-------------------------------
O SnapRAID identifica um link físico como o arquivo original e representa
os outros links físicos como referências a ele. Qual link é selecionado
como o arquivo original depende da ordem em que as entradas do diretório
são verificadas.
Se essa ordem mudar, por exemplo, após arquivos serem renomeados,
restaurados ou diretórios serem recriados, o "diff" poderá relatar aparentes
movimentações, atualizações, adições ou remoções, mesmo quando os arquivos
vinculados ainda representarem os mesmos dados.
Isso não indica corrupção de dados, mas as diferenças relatadas podem ser
confusas e podem não corresponder diretamente às operações executadas no
sistema de arquivos.
16.4 Modificações de arquivo no local sem alteração de data/hora
16.3 Modificações de arquivo no local sem alteração de data/hora
----------------------------------------------------------------
O SnapRAID detecta modificações em arquivos comparando tamanhos de arquivo e
@ -2006,7 +1989,7 @@ de data/hora de modificação do arquivo (por exemplo, com o utilitário "touch"
Caso contrário, a diferença só será detectada como uma incompatibilidade de
hash durante um "scrub" ou "check" subsequente.
16.5 Correspondência de maiúsculas/minúsculas não-ASCII no Windows
16.4 Correspondência de maiúsculas/minúsculas não-ASCII no Windows
------------------------------------------------------------------
O SnapRAID utiliza codificação UTF-8 padrão e previsível em todas as plataformas,
@ -2029,7 +2012,7 @@ maiúsculas/minúsculas. Para evitar discrepâncias decorrentes da conversão do
Windows, sempre especifique a combinação exata de maiúsculas e minúsculas para
caracteres não-ASCII em caminhos de configuração e filtros.
16.6 Sufixo de arquivos irrecuperáveis
16.5 Sufixo de arquivos irrecuperáveis
--------------------------------------
Quando o `fix` não consegue recuperar totalmente um arquivo danificado, ele o
@ -2051,7 +2034,7 @@ Evite usar a extensão `.unrecoverable` para arquivos comuns e certifique-se de
que `exclude *.unrecoverable` esteja incluído na sua configuração para evitar que
esses arquivos sejam rastreados no conjunto de dados de paridade.
16.7 Recuperação com fix parcial
16.6 Recuperação com fix parcial
--------------------------------
Quando o `fix` é restrito usando `-S, --start` ou `-B, --count`,
@ -2073,6 +2056,32 @@ normalmente após a falha de um `fix` normal. Se um `fix` parcial relatar
dados irrecuperáveis, remova ou renomeie os arquivos afetados antes de tentar
outra recuperação, ou verifique manualmente seu conteúdo.
16.7 Links físicos no NTFS e caminhos excluídos
-----------------------------------------------
No NTFS, as entradas de diretório armazenam em cache o tamanho do arquivo
e os registros de data/hora de forma independente para cada link físico.
Quando um arquivo é modificado por meio de um link, as entradas de diretório
de outros links que apontam para o mesmo arquivo podem reter metadados
obsoletos até que sejam acessadas.
O SnapRAID detecta e normaliza automaticamente essa condição sempre que
pelo menos dois links físicos para o mesmo arquivo são encontrados durante
uma verificação. No entanto, se apenas um link físico for verificado
enquanto os outros forem excluídos por filtros ou residirem fora do caminho
do disco de dados, o SnapRAID não conseguirá detectar a colisão de inodes e
dependerá dos metadados em cache do único link visível.
Consequentemente, modificações feitas por meio de um link físico excluído
ou externo podem passar despercebidas pelo SnapRAID até que os metadados do
link incluído sejam atualizados pelo sistema operacional (como quando o
arquivo é acessado ou aberto por meio desse caminho).
Para evitar essa limitação, evite modificar arquivos protegidos por meio
de links físicos excluídos do SnapRAID, ou certifique-se de que todos os
links físicos de um arquivo sejam incluídos na verificação para que o
SnapRAID possa normalizá-los.
17 TRADUçãO (TRANSLATION)
=========================

36
doc/snapraid-ro.1
View file

@ -2300,19 +2300,6 @@ sistemul de fișiere activ poate deveni vizibil.
.PP
Nu plasați puncte de montare imbricate sau montări bind în interiorul discurilor
de date când instantaneele sistemului de fișiere sunt activate.
.SS Legături dure (Hard links)
SnapRAID identifică o legătură dură ca fișier original și reprezintă celelalte
legături dure ca referințe la acesta. Care legătură este selectată ca fișier
original depinde de ordinea în care sunt scanate intrările din director.
.PP
Dacă această ordine se modifică, de exemplu după redenumirea, restaurarea
fișierelor sau recrearea directoarelor, \[dq]diff\[dq] poate raporta mutări,
actualizări, adăugiri sau eliminări aparente chiar și atunci când fișierele
legate reprezintă în continuare aceleași date.
.PP
Acest lucru nu indică coruperea datelor, dar diferențele raportate pot fi
confuze și s\-ar putea să nu corespundă direct operațiunilor efectuate în
sistemul de fișiere.
.SS Modificări ale fișierelor pe loc fără schimbarea marcajului temporal
SnapRAID detectează modificările fișierelor comparând dimensiunile fișierelor
și marcajele temporale de modificare (mtime).
@ -2384,6 +2371,29 @@ Opțiunile \`\-S\` și \`\-B\` sunt destinate exclusiv recuperării manuale avan
de obicei după ce un \`fix\` normal a eșuat. Dacă un \`fix\` parțial raportează
date nerecuperabile, eliminați sau redenumiți fișierele afectate înainte de a
încerca o nouă recuperare, sau verificați manual conținutul acestora.
.SS Legături dure NTFS și căi excluse
Pe NTFS, intrările din director memorează în cache dimensiunea fișierului
și marcajele temporale în mod independent pentru fiecare legătură dură.
Când un fișier este modificat printr\-o legătură, intrările din director ale
celorlalte legături care indică spre același fișier pot păstra metadate
învechite până când sunt accesate.
.PP
SnapRAID detectează și normalizează automat această stare ori de câte ori
întâlnește cel puțin două legături dure către același fișier în timpul unei
scanări. Cu toate acestea, dacă este scanată o singură legătură dură în
timp ce celelalte sunt excluse prin filtre sau se află în afara căii
discului de date, SnapRAID nu poate detecta coliziunea de inoduri și se
bazează pe metadatele din cache ale singurei legături vizibile.
.PP
Prin urmare, modificările efectuate printr\-o legătură dură exclusă sau
externă pot trece neobservate de SnapRAID până când metadatele legăturii
incluse sunt reîmprospătate de sistemul de operare (cum ar fi atunci când
fișierul este accesat sau deschis prin acea cale).
.PP
Pentru a evita această limitare, evitați modificarea fișierelor protejate
prin legături dure care sunt excluse din SnapRAID, sau asigurați\-vă că toate
legăturile dure către un fișier sunt incluse în scanare, astfel încât
SnapRAID să le poată normaliza.
.SH TRADUCERE (TRANSLATION)
Acest document este o traducere automată a manualului în limba engleză.
Consultați manualul în limba engleză pentru versiunea oficială.

38
doc/snapraid-ro.d
View file

@ -1798,20 +1798,6 @@ Probleme Cunoscute (Known Issues)
Nu plasați puncte de montare imbricate sau montări bind în interiorul discurilor
de date când instantaneele sistemului de fișiere sunt activate.
Legături dure (Hard links)
SnapRAID identifică o legătură dură ca fișier original și reprezintă celelalte
legături dure ca referințe la acesta. Care legătură este selectată ca fișier
original depinde de ordinea în care sunt scanate intrările din director.
Dacă această ordine se modifică, de exemplu după redenumirea, restaurarea
fișierelor sau recrearea directoarelor, "diff" poate raporta mutări,
actualizări, adăugiri sau eliminări aparente chiar și atunci când fișierele
legate reprezintă în continuare aceleași date.
Acest lucru nu indică coruperea datelor, dar diferențele raportate pot fi
confuze și s-ar putea să nu corespundă direct operațiunilor efectuate în
sistemul de fișiere.
Modificări ale fișierelor pe loc fără schimbarea marcajului temporal
SnapRAID detectează modificările fișierelor comparând dimensiunile fișierelor
și marcajele temporale de modificare (mtime).
@ -1887,6 +1873,30 @@ Probleme Cunoscute (Known Issues)
date nerecuperabile, eliminați sau redenumiți fișierele afectate înainte de a
încerca o nouă recuperare, sau verificați manual conținutul acestora.
Legături dure NTFS și căi excluse
Pe NTFS, intrările din director memorează în cache dimensiunea fișierului
și marcajele temporale în mod independent pentru fiecare legătură dură.
Când un fișier este modificat printr-o legătură, intrările din director ale
celorlalte legături care indică spre același fișier pot păstra metadate
învechite până când sunt accesate.
SnapRAID detectează și normalizează automat această stare ori de câte ori
întâlnește cel puțin două legături dure către același fișier în timpul unei
scanări. Cu toate acestea, dacă este scanată o singură legătură dură în
timp ce celelalte sunt excluse prin filtre sau se află în afara căii
discului de date, SnapRAID nu poate detecta coliziunea de inoduri și se
bazează pe metadatele din cache ale singurei legături vizibile.
Prin urmare, modificările efectuate printr-o legătură dură exclusă sau
externă pot trece neobservate de SnapRAID până când metadatele legăturii
incluse sunt reîmprospătate de sistemul de operare (cum ar fi atunci când
fișierul este accesat sau deschis prin acea cale).
Pentru a evita această limitare, evitați modificarea fișierelor protejate
prin legături dure care sunt excluse din SnapRAID, sau asigurați-vă că toate
legăturile dure către un fișier sunt incluse în scanare, astfel încât
SnapRAID să le poată normaliza.
Traducere (Translation)
Acest document este o traducere automată a manualului în limba engleză.
Consultați manualul în limba engleză pentru versiunea oficială.

50
doc/snapraid-ro.txt
View file

@ -1933,23 +1933,7 @@ sistemul de fișiere activ poate deveni vizibil.
Nu plasați puncte de montare imbricate sau montări bind în interiorul discurilor
de date când instantaneele sistemului de fișiere sunt activate.
16.3 Legături dure (Hard links)
-------------------------------
SnapRAID identifică o legătură dură ca fișier original și reprezintă celelalte
legături dure ca referințe la acesta. Care legătură este selectată ca fișier
original depinde de ordinea în care sunt scanate intrările din director.
Dacă această ordine se modifică, de exemplu după redenumirea, restaurarea
fișierelor sau recrearea directoarelor, "diff" poate raporta mutări,
actualizări, adăugiri sau eliminări aparente chiar și atunci când fișierele
legate reprezintă în continuare aceleași date.
Acest lucru nu indică coruperea datelor, dar diferențele raportate pot fi
confuze și s-ar putea să nu corespundă direct operațiunilor efectuate în
sistemul de fișiere.
16.4 Modificări ale fișierelor pe loc fără schimbarea marcajului temporal
16.3 Modificări ale fișierelor pe loc fără schimbarea marcajului temporal
-------------------------------------------------------------------------
SnapRAID detectează modificările fișierelor comparând dimensiunile fișierelor
@ -1965,7 +1949,7 @@ marcajul temporal de modificare al fișierului (de exemplu, cu utilitarul
"touch"). În caz contrar, diferența va fi detectată doar ca o neconcordanță
de hash în timpul unui "scrub" sau "check" ulterior.
16.5 Potrivirea majusculelor/minusculelor non-ASCII în Windows
16.4 Potrivirea majusculelor/minusculelor non-ASCII în Windows
--------------------------------------------------------------
SnapRAID utilizează codificarea UTF-8 standard și previzibilă pe toate
@ -1988,7 +1972,7 @@ distincție între majuscule și minuscule. Pentru a preveni discrepanțele apă
din conversia efectuată de Windows, specificați întotdeauna forma exactă a
caracterelor non-ASCII în căile de configurare și filtre.
16.6 Sufixul fișierelor nerecuperabile
16.5 Sufixul fișierelor nerecuperabile
--------------------------------------
Când `fix` nu poate recupera complet un fișier deteriorat, îl plasează în
@ -2010,7 +1994,7 @@ Evitați utilizarea extensiei `.unrecoverable` pentru fișiere obișnuite și
asigurați-vă că `exclude *.unrecoverable` este inclus în configurație pentru
a preveni urmărirea acestor fișiere în setul de date de paritate.
16.7 Recuperare cu fix parțial
16.6 Recuperare cu fix parțial
------------------------------
Când `fix` este restricționat folosind `-S, --start` sau `-B, --count`,
@ -2032,6 +2016,32 @@ de obicei după ce un `fix` normal a eșuat. Dacă un `fix` parțial raportează
date nerecuperabile, eliminați sau redenumiți fișierele afectate înainte de a
încerca o nouă recuperare, sau verificați manual conținutul acestora.
16.7 Legături dure NTFS și căi excluse
--------------------------------------
Pe NTFS, intrările din director memorează în cache dimensiunea fișierului
și marcajele temporale în mod independent pentru fiecare legătură dură.
Când un fișier este modificat printr-o legătură, intrările din director ale
celorlalte legături care indică spre același fișier pot păstra metadate
învechite până când sunt accesate.
SnapRAID detectează și normalizează automat această stare ori de câte ori
întâlnește cel puțin două legături dure către același fișier în timpul unei
scanări. Cu toate acestea, dacă este scanată o singură legătură dură în
timp ce celelalte sunt excluse prin filtre sau se află în afara căii
discului de date, SnapRAID nu poate detecta coliziunea de inoduri și se
bazează pe metadatele din cache ale singurei legături vizibile.
Prin urmare, modificările efectuate printr-o legătură dură exclusă sau
externă pot trece neobservate de SnapRAID până când metadatele legăturii
incluse sunt reîmprospătate de sistemul de operare (cum ar fi atunci când
fișierul este accesat sau deschis prin acea cale).
Pentru a evita această limitare, evitați modificarea fișierelor protejate
prin legături dure care sunt excluse din SnapRAID, sau asigurați-vă că toate
legăturile dure către un fișier sunt incluse în scanare, astfel încât
SnapRAID să le poată normaliza.
17 TRADUCERE (TRANSLATION)
==========================

34
doc/snapraid-ru.1
View file

@ -2305,19 +2305,6 @@ bind\-монтирования внутри диска данных не под
.PP
Не размещайте вложенные точки монтирования или bind\-монтирования внутри дисков
данных, когда включены снимки файловой системы.
.SS Жесткие ссылки (Hard links)
SnapRAID определяет одну жесткую ссылку как исходный файл и представляет
другие жесткие ссылки как ссылки на него. Какая ссылка выбирается в качестве
исходного файла, зависит от порядка сканирования записей каталога.
.PP
Если этот порядок изменяется, например, после переименования, восстановления
файлов или повторного создания каталогов, команда \[dq]diff\[dq] может сообщать о
видимых перемещениях, обновлениях, добавлениях или удалениях, даже когда
связанные файлы по\-прежнему представляют те же данные.
.PP
Это не указывает на повреждение данных, но сообщаемые различия могут сбивать
с толку и могут не соответствовать напрямую операциям, выполненным в файловой
системе.
.SS Изменения файлов на месте без изменения временных меток
SnapRAID обнаруживает изменения файлов путем сравнения размеров файлов и
временных меток модификации (mtime).
@ -2389,6 +2376,27 @@ SnapRAID работает только с выбранными блоками и
восстановления, обычно после сбоя обычного \`fix\`. Если частичный \`fix\` сообщает
о невосстановимых данных, удалите или переименуйте затронутые файлы перед
попыткой повторного восстановления либо проверьте их содержимое вручную.
.SS Жесткие ссылки NTFS и исключенные пути
В NTFS записи каталогов кэшируют размер файла и временные метки независимо
для каждой жесткой ссылки. Когда файл изменяется через одну ссылку, записи
каталогов других ссылок, указывающих на тот же файл, могут сохранять
устаревшие метаданные до тех пор, пока к ним не будет осуществлен доступ.
.PP
SnapRAID автоматически обнаруживает и нормализует это состояние всякий
раз, когда во время сканирования обнаруживаются как минимум две жесткие
ссылки на один и тот же файл. Однако если сканируется только одна жесткая
ссылка, тогда как другие исключены фильтрами или находятся за пределами
пути диска данных, SnapRAID не может обнаружить коллизию inode и полагается
на кэшированные метаданные единственной видимой ссылки.
.PP
Следовательно, изменения, внесенные через исключенную или внешнюю жесткую
ссылку, могут остаться незамеченными SnapRAID до тех пор, пока метаданные
включенной ссылки не будут обновлены операционной системой (например,
когда к файлу обращаются или открывают его по этому пути).
.PP
Чтобы избежать этого ограничения, не изменяйте защищенные файлы через
жесткие ссылки, исключенные из SnapRAID, либо убедитесь, что все жесткие
ссылки на файл включены в сканирование, чтобы SnapRAID мог их нормализовать.
.SH Перевод (TRANSLATION)
Этот документ является автоматическим переводом английского руководства.
Обратитесь к английскому руководству за официальной версией.

36
doc/snapraid-ru.d
View file

@ -1805,20 +1805,6 @@ Name{number}
Не размещайте вложенные точки монтирования или bind-монтирования внутри дисков
данных, когда включены снимки файловой системы.
Жесткие ссылки (Hard links)
SnapRAID определяет одну жесткую ссылку как исходный файл и представляет
другие жесткие ссылки как ссылки на него. Какая ссылка выбирается в качестве
исходного файла, зависит от порядка сканирования записей каталога.
Если этот порядок изменяется, например, после переименования, восстановления
файлов или повторного создания каталогов, команда "diff" может сообщать о
видимых перемещениях, обновлениях, добавлениях или удалениях, даже когда
связанные файлы по-прежнему представляют те же данные.
Это не указывает на повреждение данных, но сообщаемые различия могут сбивать
с толку и могут не соответствовать напрямую операциям, выполненным в файловой
системе.
Изменения файлов на месте без изменения временных меток
SnapRAID обнаруживает изменения файлов путем сравнения размеров файлов и
временных меток модификации (mtime).
@ -1894,6 +1880,28 @@ Name{number}
о невосстановимых данных, удалите или переименуйте затронутые файлы перед
попыткой повторного восстановления либо проверьте их содержимое вручную.
Жесткие ссылки NTFS и исключенные пути
В NTFS записи каталогов кэшируют размер файла и временные метки независимо
для каждой жесткой ссылки. Когда файл изменяется через одну ссылку, записи
каталогов других ссылок, указывающих на тот же файл, могут сохранять
устаревшие метаданные до тех пор, пока к ним не будет осуществлен доступ.
SnapRAID автоматически обнаруживает и нормализует это состояние всякий
раз, когда во время сканирования обнаруживаются как минимум две жесткие
ссылки на один и тот же файл. Однако если сканируется только одна жесткая
ссылка, тогда как другие исключены фильтрами или находятся за пределами
пути диска данных, SnapRAID не может обнаружить коллизию inode и полагается
на кэшированные метаданные единственной видимой ссылки.
Следовательно, изменения, внесенные через исключенную или внешнюю жесткую
ссылку, могут остаться незамеченными SnapRAID до тех пор, пока метаданные
включенной ссылки не будут обновлены операционной системой (например,
когда к файлу обращаются или открывают его по этому пути).
Чтобы избежать этого ограничения, не изменяйте защищенные файлы через
жесткие ссылки, исключенные из SnapRAID, либо убедитесь, что все жесткие
ссылки на файл включены в сканирование, чтобы SnapRAID мог их нормализовать.
Перевод (Translation)
Этот документ является автоматическим переводом английского руководства.
Обратитесь к английскому руководству за официальной версией.

48
doc/snapraid-ru.txt
View file

@ -1940,23 +1940,7 @@ bind-монтирования внутри диска данных не подд
Не размещайте вложенные точки монтирования или bind-монтирования внутри дисков
данных, когда включены снимки файловой системы.
16.3 Жесткие ссылки (Hard links)
--------------------------------
SnapRAID определяет одну жесткую ссылку как исходный файл и представляет
другие жесткие ссылки как ссылки на него. Какая ссылка выбирается в качестве
исходного файла, зависит от порядка сканирования записей каталога.
Если этот порядок изменяется, например, после переименования, восстановления
файлов или повторного создания каталогов, команда "diff" может сообщать о
видимых перемещениях, обновлениях, добавлениях или удалениях, даже когда
связанные файлы по-прежнему представляют те же данные.
Это не указывает на повреждение данных, но сообщаемые различия могут сбивать
с толку и могут не соответствовать напрямую операциям, выполненным в файловой
системе.
16.4 Изменения файлов на месте без изменения временных меток
16.3 Изменения файлов на месте без изменения временных меток
------------------------------------------------------------
SnapRAID обнаруживает изменения файлов путем сравнения размеров файлов и
@ -1971,7 +1955,7 @@ SnapRAID обнаруживает изменения файлов путем с
случае различие будет обнаружено только как несоответствие хэша во время
последующего "scrub" или "check".
16.5 Сопоставление регистра символов non-ASCII в Windows
16.4 Сопоставление регистра символов non-ASCII в Windows
--------------------------------------------------------
SnapRAID использует стандартную, предсказуемую кодировку UTF-8 на всех
@ -1995,7 +1979,7 @@ Windows и ее упорным стремлением к псевдонимиз
всегда указывайте точный регистр для любых символов non-ASCII в путях
конфигурации и фильтрах.
16.6 Суффикс невосстановимых файлов
16.5 Суффикс невосстановимых файлов
-----------------------------------
Когда `fix` не может полностью восстановить поврежденный файл, он помещает его
@ -2017,7 +2001,7 @@ SnapRAID удаляет устаревший файл `.unrecoverable`. Кара
убедитесь, что в вашей конфигурации указано правило `exclude *.unrecoverable`,
чтобы такие файлы не отслеживались в наборе данных четности.
16.7 Восстановление с частичным fix
16.6 Восстановление с частичным fix
-----------------------------------
Когда `fix` ограничен с помощью `-S, --start` или `-B, --count`,
@ -2039,6 +2023,30 @@ SnapRAID работает только с выбранными блоками и
о невосстановимых данных, удалите или переименуйте затронутые файлы перед
попыткой повторного восстановления либо проверьте их содержимое вручную.
16.7 Жесткие ссылки NTFS и исключенные пути
-------------------------------------------
В NTFS записи каталогов кэшируют размер файла и временные метки независимо
для каждой жесткой ссылки. Когда файл изменяется через одну ссылку, записи
каталогов других ссылок, указывающих на тот же файл, могут сохранять
устаревшие метаданные до тех пор, пока к ним не будет осуществлен доступ.
SnapRAID автоматически обнаруживает и нормализует это состояние всякий
раз, когда во время сканирования обнаруживаются как минимум две жесткие
ссылки на один и тот же файл. Однако если сканируется только одна жесткая
ссылка, тогда как другие исключены фильтрами или находятся за пределами
пути диска данных, SnapRAID не может обнаружить коллизию inode и полагается
на кэшированные метаданные единственной видимой ссылки.
Следовательно, изменения, внесенные через исключенную или внешнюю жесткую
ссылку, могут остаться незамеченными SnapRAID до тех пор, пока метаданные
включенной ссылки не будут обновлены операционной системой (например,
когда к файлу обращаются или открывают его по этому пути).
Чтобы избежать этого ограничения, не изменяйте защищенные файлы через
жесткие ссылки, исключенные из SnapRAID, либо убедитесь, что все жесткие
ссылки на файл включены в сканирование, чтобы SnapRAID мог их нормализовать.
17 Перевод (TRANSLATION)
========================

34
doc/snapraid-sv.1
View file

@ -2302,19 +2302,6 @@ skanning av en ögonblicksbild.
.PP
Placera inte kapslade monteringspunkter eller bind\-monteringar inuti
datadiskar när filsystemögonblicksbilder är aktiverade.
.SS Hårda länkar (Hard links)
SnapRAID identifierar en hård länk som originalfilen och representerar de
andra hårda länkarna som referenser till den. Vilken länk som väljs som
originalfil beror på i vilken ordning katalogposterna skannas.
.PP
Om denna ordning ändras, till exempel efter att filer bytt namn, återställts
eller kataloger återskapats, kan \[dq]diff\[dq] rapportera skenbara flyttar,
uppdateringar, tillägg eller borttagningar även när de länkade filerna
fortfarande representerar samma data.
.PP
Detta indikerar inte datakorruption, men de rapporterade skillnaderna kan
vara förvirrande och kanske inte direkt motsvarar de filsystemsoperationer
som utfördes.
.SS Filändringar på plats utan tidsstämpeländringar
SnapRAID upptäcker filändringar genom att jämföra filstorlekar och
ändringstidsstämplar (mtime).
@ -2381,6 +2368,27 @@ Alternativen \`\-S\` och \`\-B\` är endast avsedda för avancerad manuell åter
vanligtvis efter att en normal \`fix\` har misslyckats. Om en partiell \`fix\`
rapporterar oåterkalleliga data, ta bort eller byt namn på de berörda filerna
innan du försöker med en ny återställning, eller verifiera deras innehåll manuellt.
.SS NTFS hårda länkar och exkluderade sökvägar
På NTFS cachelagrar katalogposter filstorlek och tidsstämplar oberoende
för varje hård länk. När en fil modifieras via en länk kan katalogposterna
för andra länkar som pekar på samma fil behålla inaktuella metadata tills
de används.
.PP
SnapRAID upptäcker och normaliserar automatiskt detta tillstånd när minst
två hårda länkar till samma fil påträffas under en skanning. Men om endast
en hård länk skannas medan de andra exkluderas av filter eller ligger
utanför hårddiskens sökväg för data, kan SnapRAID inte upptäcka
inodkollisionen och förlitar sig på cachade metadata för den enda synliga
länken.
.PP
Följaktligen kan ändringar som görs via en exkluderad eller extern hård länk
gå obemärkta förbi för SnapRAID tills metadatan för den inkluderade länken
uppdateras av operativsystemet (till exempel när filen nås eller öppnas via
den sökvägen).
.PP
För att undvika denna begränsning, undvik att modifiera skyddade filer via
hårda länkar som är exkluderade från SnapRAID, eller se till att alla hårda
länkar till en fil inkluderas i skanningen så att SnapRAID kan normalisera dem.
.SH ÖVERSäTTNING (TRANSLATION)
Detta dokument är en automatisk översättning av den engelska manualen.
Se den engelska manualen för den officiella versionen.

36
doc/snapraid-sv.d
View file

@ -1800,20 +1800,6 @@ Kända problem (Known Issues)
Placera inte kapslade monteringspunkter eller bind-monteringar inuti
datadiskar när filsystemögonblicksbilder är aktiverade.
Hårda länkar (Hard links)
SnapRAID identifierar en hård länk som originalfilen och representerar de
andra hårda länkarna som referenser till den. Vilken länk som väljs som
originalfil beror på i vilken ordning katalogposterna skannas.
Om denna ordning ändras, till exempel efter att filer bytt namn, återställts
eller kataloger återskapats, kan "diff" rapportera skenbara flyttar,
uppdateringar, tillägg eller borttagningar även när de länkade filerna
fortfarande representerar samma data.
Detta indikerar inte datakorruption, men de rapporterade skillnaderna kan
vara förvirrande och kanske inte direkt motsvarar de filsystemsoperationer
som utfördes.
Filändringar på plats utan tidsstämpeländringar
SnapRAID upptäcker filändringar genom att jämföra filstorlekar och
ändringstidsstämplar (mtime).
@ -1884,6 +1870,28 @@ Kända problem (Known Issues)
rapporterar oåterkalleliga data, ta bort eller byt namn på de berörda filerna
innan du försöker med en ny återställning, eller verifiera deras innehåll manuellt.
NTFS hårda länkar och exkluderade sökvägar
På NTFS cachelagrar katalogposter filstorlek och tidsstämplar oberoende
för varje hård länk. När en fil modifieras via en länk kan katalogposterna
för andra länkar som pekar på samma fil behålla inaktuella metadata tills
de används.
SnapRAID upptäcker och normaliserar automatiskt detta tillstånd när minst
två hårda länkar till samma fil påträffas under en skanning. Men om endast
en hård länk skannas medan de andra exkluderas av filter eller ligger
utanför hårddiskens sökväg för data, kan SnapRAID inte upptäcka
inodkollisionen och förlitar sig på cachade metadata för den enda synliga
länken.
Följaktligen kan ändringar som görs via en exkluderad eller extern hård länk
gå obemärkta förbi för SnapRAID tills metadatan för den inkluderade länken
uppdateras av operativsystemet (till exempel när filen nås eller öppnas via
den sökvägen).
För att undvika denna begränsning, undvik att modifiera skyddade filer via
hårda länkar som är exkluderade från SnapRAID, eller se till att alla hårda
länkar till en fil inkluderas i skanningen så att SnapRAID kan normalisera dem.
Översättning (Translation)
Detta dokument är en automatisk översättning av den engelska manualen.
Se den engelska manualen för den officiella versionen.

48
doc/snapraid-sv.txt
View file

@ -1935,23 +1935,7 @@ skanning av en ögonblicksbild.
Placera inte kapslade monteringspunkter eller bind-monteringar inuti
datadiskar när filsystemögonblicksbilder är aktiverade.
16.3 Hårda länkar (Hard links)
------------------------------
SnapRAID identifierar en hård länk som originalfilen och representerar de
andra hårda länkarna som referenser till den. Vilken länk som väljs som
originalfil beror på i vilken ordning katalogposterna skannas.
Om denna ordning ändras, till exempel efter att filer bytt namn, återställts
eller kataloger återskapats, kan "diff" rapportera skenbara flyttar,
uppdateringar, tillägg eller borttagningar även när de länkade filerna
fortfarande representerar samma data.
Detta indikerar inte datakorruption, men de rapporterade skillnaderna kan
vara förvirrande och kanske inte direkt motsvarar de filsystemsoperationer
som utfördes.
16.4 Filändringar på plats utan tidsstämpeländringar
16.3 Filändringar på plats utan tidsstämpeländringar
----------------------------------------------------
SnapRAID upptäcker filändringar genom att jämföra filstorlekar och
@ -1966,7 +1950,7 @@ filens ändringstidsstämpel (till exempel med verktyget "touch"). Annars
kommer skillnaden endast att upptäckas som en hash-avvikelse under en
efterföljande "scrub" eller "check".
16.5 Icke-ASCII skiftlägesmatchning i Windows
16.4 Icke-ASCII skiftlägesmatchning i Windows
---------------------------------------------
SnapRAID använder standardiserad, förutsägbar UTF-8-kodning på alla plattformar
@ -1985,7 +1969,7 @@ och dess insisterande på skiftlägesokänslig aliasning. För att förhindra
avvikelser till följd av Windows skiftlägesvikning, ange alltid det exakta
skiftläget för eventuella icke-ASCII-tecken i konfigurationssökvägar och filter.
16.6 Suffix för oåterkalleliga filer
16.5 Suffix för oåterkalleliga filer
------------------------------------
När `fix` inte helt kan återställa en skadad fil sätter den filen i karantän
@ -2007,7 +1991,7 @@ Undvik att använda filändelsen `.unrecoverable` för vanliga filer och se till
att `exclude *.unrecoverable` ingår i din konfiguration för att förhindra att
sådana filer spåras i paritetsdatamängden.
16.7 Återställning med partiell fix
16.6 Återställning med partiell fix
-----------------------------------
När `fix` begränsas med `-S, --start` eller `-B, --count`,
@ -2029,6 +2013,30 @@ vanligtvis efter att en normal `fix` har misslyckats. Om en partiell `fix`
rapporterar oåterkalleliga data, ta bort eller byt namn på de berörda filerna
innan du försöker med en ny återställning, eller verifiera deras innehåll manuellt.
16.7 NTFS hårda länkar och exkluderade sökvägar
-----------------------------------------------
På NTFS cachelagrar katalogposter filstorlek och tidsstämplar oberoende
för varje hård länk. När en fil modifieras via en länk kan katalogposterna
för andra länkar som pekar på samma fil behålla inaktuella metadata tills
de används.
SnapRAID upptäcker och normaliserar automatiskt detta tillstånd när minst
två hårda länkar till samma fil påträffas under en skanning. Men om endast
en hård länk skannas medan de andra exkluderas av filter eller ligger
utanför hårddiskens sökväg för data, kan SnapRAID inte upptäcka
inodkollisionen och förlitar sig på cachade metadata för den enda synliga
länken.
Följaktligen kan ändringar som görs via en exkluderad eller extern hård länk
gå obemärkta förbi för SnapRAID tills metadatan för den inkluderade länken
uppdateras av operativsystemet (till exempel när filen nås eller öppnas via
den sökvägen).
För att undvika denna begränsning, undvik att modifiera skyddade filer via
hårda länkar som är exkluderade från SnapRAID, eller se till att alla hårda
länkar till en fil inkluderas i skanningen så att SnapRAID kan normalisera dem.
17 ÖVERSäTTNING (TRANSLATION)
=============================

35
doc/snapraid-uk.1
View file

@ -2506,19 +2506,6 @@ bind\-монтування всередині диска даних не під
.PP
Не розміщуйте вкладені точки монтування або bind\-монтування всередині дисків
даних, коли ввімкнено знімки файлової системи.
.SS Жорсткі посилання (Hard links)
SnapRAID визначає одне жорстке посилання як оригінальний файл і представляє
інші жорсткі посилання як посилання на нього. Яке саме посилання вибирається
як оригінальний файл, залежить від порядку сканування записів каталогу.
.PP
Якщо цей порядок змінюється, наприклад, після перейменування, відновлення
файлів або повторного створення каталогів, команда \[dq]diff\[dq] може повідомляти
про уявні переміщення, оновлення, додавання або видалення, навіть коли
пов\'язані файли все ще представляють ті самі дані.
.PP
Це не свідчить про пошкодження даних, але повідомлені відмінності можуть
викликати плутанину і можуть не відповідати безпосередньо операціям,
виконаним у файловій системі.
.SS Модифікації файлів на місці без зміни позначок часу
SnapRAID виявляє модифікації файлів шляхом порівняння розмірів файлів та
позначок часу модифікації (mtime).
@ -2587,6 +2574,28 @@ SnapRAID працює лише з вибраними блоками і не ви
зазвичай після збою звичайного \`fix\`. Якщо частковий \`fix\` повідомляє про
невідновлювані дані, видаліть або перейменуйте уражені файли перед спробою
повторного відновлення або перевірте їхній вміст вручну.
.SS Жорсткі посилання NTFS та виключені шляхи
У файловій системі NTFS записи каталогів кешують розмір файлу та часові
позначки незалежно для кожного жорсткого посилання. Коли файл змінюється
через одне посилання, записи каталогів інших посилань, що вказують на
той самий файл, можуть зберігати застарілі метадані, доки до них не
буде здійснено доступ.
.PP
SnapRAID автоматично виявляє та нормалізує цей стан щоразу, коли під
час сканування виявляється щонайменше два жорстких посилання на один
і той самий файл. Однак, якщо сканується лише одне жорстке посилання,
тоді як інші виключені фільтрами або знаходяться за межами шляху диска
даних, SnapRAID не може виявити колізію inode і покладається на
кешовані метадані єдиного видимого посилання.
.PP
Отже, зміни, внесені через виключене або зовнішнє жорстке посилання,
можуть залишитися непоміченими для SnapRAID, доки метадані включеного
посилання не будуть оновлені операційною системою (наприклад, коли до
файлу звертаються або відкривають його за цим шляхом).
.PP
Щоб уникнути цього обмеження, не змінюйте захищені файли через жорсткі
посилання, виключені зі SnapRAID, або переконайтеся, що всі жорсткі
посилання на файл включені до сканування, щоб SnapRAID міг їх нормалізувати.
.SH Переклад (TRANSLATION)
Цей документ є автоматичним перекладом англійського посібника.
Зверніться до англійського посібника для отримання офіційної версії.

37
doc/snapraid-uk.d
View file

@ -1992,20 +1992,6 @@ Name{number}
Не розміщуйте вкладені точки монтування або bind-монтування всередині дисків
даних, коли ввімкнено знімки файлової системи.
Жорсткі посилання (Hard links)
SnapRAID визначає одне жорстке посилання як оригінальний файл і представляє
інші жорсткі посилання як посилання на нього. Яке саме посилання вибирається
як оригінальний файл, залежить від порядку сканування записів каталогу.
Якщо цей порядок змінюється, наприклад, після перейменування, відновлення
файлів або повторного створення каталогів, команда "diff" може повідомляти
про уявні переміщення, оновлення, додавання або видалення, навіть коли
пов'язані файли все ще представляють ті самі дані.
Це не свідчить про пошкодження даних, але повідомлені відмінності можуть
викликати плутанину і можуть не відповідати безпосередньо операціям,
виконаним у файловій системі.
Модифікації файлів на місці без зміни позначок часу
SnapRAID виявляє модифікації файлів шляхом порівняння розмірів файлів та
позначок часу модифікації (mtime).
@ -2078,6 +2064,29 @@ Name{number}
невідновлювані дані, видаліть або перейменуйте уражені файли перед спробою
повторного відновлення або перевірте їхній вміст вручну.
Жорсткі посилання NTFS та виключені шляхи
У файловій системі NTFS записи каталогів кешують розмір файлу та часові
позначки незалежно для кожного жорсткого посилання. Коли файл змінюється
через одне посилання, записи каталогів інших посилань, що вказують на
той самий файл, можуть зберігати застарілі метадані, доки до них не
буде здійснено доступ.
SnapRAID автоматично виявляє та нормалізує цей стан щоразу, коли під
час сканування виявляється щонайменше два жорстких посилання на один
і той самий файл. Однак, якщо сканується лише одне жорстке посилання,
тоді як інші виключені фільтрами або знаходяться за межами шляху диска
даних, SnapRAID не може виявити колізію inode і покладається на
кешовані метадані єдиного видимого посилання.
Отже, зміни, внесені через виключене або зовнішнє жорстке посилання,
можуть залишитися непоміченими для SnapRAID, доки метадані включеного
посилання не будуть оновлені операційною системою (наприклад, коли до
файлу звертаються або відкривають його за цим шляхом).
Щоб уникнути цього обмеження, не змінюйте захищені файли через жорсткі
посилання, виключені зі SnapRAID, або переконайтеся, що всі жорсткі
посилання на файл включені до сканування, щоб SnapRAID міг їх нормалізувати.
Переклад (Translation)
Цей документ є автоматичним перекладом англійського посібника.
Зверніться до англійського посібника для отримання офіційної версії.

49
doc/snapraid-uk.txt
View file

@ -2127,23 +2127,7 @@ bind-монтування всередині диска даних не підт
Не розміщуйте вкладені точки монтування або bind-монтування всередині дисків
даних, коли ввімкнено знімки файлової системи.
16.3 Жорсткі посилання (Hard links)
-----------------------------------
SnapRAID визначає одне жорстке посилання як оригінальний файл і представляє
інші жорсткі посилання як посилання на нього. Яке саме посилання вибирається
як оригінальний файл, залежить від порядку сканування записів каталогу.
Якщо цей порядок змінюється, наприклад, після перейменування, відновлення
файлів або повторного створення каталогів, команда "diff" може повідомляти
про уявні переміщення, оновлення, додавання або видалення, навіть коли
пов'язані файли все ще представляють ті самі дані.
Це не свідчить про пошкодження даних, але повідомлені відмінності можуть
викликати плутанину і можуть не відповідати безпосередньо операціям,
виконаним у файловій системі.
16.4 Модифікації файлів на місці без зміни позначок часу
16.3 Модифікації файлів на місці без зміни позначок часу
--------------------------------------------------------
SnapRAID виявляє модифікації файлів шляхом порівняння розмірів файлів та
@ -2158,7 +2142,7 @@ SnapRAID виявляє модифікації файлів шляхом пор
випадку різниця буде виявлена лише як невідповідність хешу під час
наступного "scrub" або "check".
16.5 Зіставлення регістру символів non-ASCII у Windows
16.4 Зіставлення регістру символів non-ASCII у Windows
------------------------------------------------------
SnapRAID використовує стандартне, передбачуване кодування UTF-8 на всіх
@ -2179,7 +2163,7 @@ SnapRAID використовує стандартне, передбачуван
точний регістр для будь-яких символів non-ASCII у шляхах конфігурації та
фільтрах.
16.6 Суфікс невідновлюваних файлів
16.5 Суфікс невідновлюваних файлів
----------------------------------
Коли `fix` не може повністю відновити пошкоджений файл, він поміщає його в
@ -2201,7 +2185,7 @@ SnapRAID використовує стандартне, передбачуван
переконайтеся, що правило `exclude *.unrecoverable` включено до вашої
конфігурації, щоб такі файли не відстежувалися в наборі даних парності.
16.7 Відновлення з частковим fix
16.6 Відновлення з частковим fix
--------------------------------
Коли `fix` обмежено за допомогою `-S, --start` або `-B, --count`,
@ -2223,6 +2207,31 @@ SnapRAID працює лише з вибраними блоками і не ви
невідновлювані дані, видаліть або перейменуйте уражені файли перед спробою
повторного відновлення або перевірте їхній вміст вручну.
16.7 Жорсткі посилання NTFS та виключені шляхи
----------------------------------------------
У файловій системі NTFS записи каталогів кешують розмір файлу та часові
позначки незалежно для кожного жорсткого посилання. Коли файл змінюється
через одне посилання, записи каталогів інших посилань, що вказують на
той самий файл, можуть зберігати застарілі метадані, доки до них не
буде здійснено доступ.
SnapRAID автоматично виявляє та нормалізує цей стан щоразу, коли під
час сканування виявляється щонайменше два жорстких посилання на один
і той самий файл. Однак, якщо сканується лише одне жорстке посилання,
тоді як інші виключені фільтрами або знаходяться за межами шляху диска
даних, SnapRAID не може виявити колізію inode і покладається на
кешовані метадані єдиного видимого посилання.
Отже, зміни, внесені через виключене або зовнішнє жорстке посилання,
можуть залишитися непоміченими для SnapRAID, доки метадані включеного
посилання не будуть оновлені операційною системою (наприклад, коли до
файлу звертаються або відкривають його за цим шляхом).
Щоб уникнути цього обмеження, не змінюйте захищені файли через жорсткі
посилання, виключені зі SnapRAID, або переконайтеся, що всі жорсткі
посилання на файл включені до сканування, щоб SnapRAID міг їх нормалізувати.
17 Переклад (TRANSLATION)
=========================

26
doc/snapraid-zh.1
View file

@ -2074,16 +2074,6 @@ SnapRAID 在扫描数据磁盘时不会跨越文件系统、挂载点或子卷
因此，在扫描快照时，活动文件系统中被挂载点隐藏的目录可能会变为可见。
.PP
启用文件系统快照时，请勿在数据磁盘内放置嵌套挂载点或 bind 挂载。
.SS 硬链接
SnapRAID 将一个硬链接标识为原始文件，并将其他硬链接表示为对它的引用。
选择哪个链接作为原始文件取决于扫描目录条目的顺序。
.PP
如果此顺序发生更改（例如在重命名、恢复文件或重新创建目录之后），
即使链接的文件仍然表示相同的数据，“diff” 也可能会报告表面上的移动、更新、
添加或删除。
.PP
这并不表示数据损坏，但报告的差异可能会令人困惑，并且可能与在文件系统上
执行的操作不直接对应。
.SS 未更改时间戳的原地文件修改
SnapRAID 通过比较文件大小和修改时间戳（mtime）来检测文件修改。
.PP
@ -2135,6 +2125,22 @@ SnapRAID 仅对选定的块进行操作，而不执行文件级别的最终化
\`\-S\` 和 \`\-B\` 选项仅适用于高级手动恢复，通常在常规 \`fix\` 失败后使用。
如果部分 \`fix\` 报告了无法恢复的数据，请在尝试另一次恢复之前删除受影响的
文件或对其重命名，或者手动验证其内容。
.SS NTFS 硬链接与排除的路径
在 NTFS 上，目录条目会为每个硬链接单独缓存文件大小和时间戳。
当通过其中一个链接修改文件时，指向同一文件的其他链接的目录条目
可能会保留过时的元数据，直到它们被访问为止。
.PP
如果在扫描过程中遇到同一文件的至少两个硬链接，SnapRAID 会自动
检测并规范化这种情况。但是，如果仅扫描了一个硬链接，而其他硬链接
被过滤器排除或位于数据磁盘路径之外，SnapRAID 将无法检测到 inode 冲突，
并会依赖单个可见链接的缓存元数据。
.PP
因此，通过被排除或外部的硬链接所做的修改，在操作系统刷新所包含链接
的元数据之前（例如通过该路径访问或打开文件时），可能会被 SnapRAID 忽略。
.PP
为避免此限制，请避免通过已从 SnapRAID 中排除的硬链接来修改受保护
的文件，或者确保文件的所有硬链接都包含在扫描中，以便 SnapRAID 可以
对它们进行规范化。
.SH 翻译 (TRANSLATION)
本文档是英文手册的自动翻译。
请参阅英文手册以获取权威版本。

28
doc/snapraid-zh.d
View file

@ -1572,17 +1572,6 @@ Name{number}
启用文件系统快照时，请勿在数据磁盘内放置嵌套挂载点或 bind 挂载。
硬链接
SnapRAID 将一个硬链接标识为原始文件，并将其他硬链接表示为对它的引用。
选择哪个链接作为原始文件取决于扫描目录条目的顺序。
如果此顺序发生更改（例如在重命名、恢复文件或重新创建目录之后），
即使链接的文件仍然表示相同的数据，“diff” 也可能会报告表面上的移动、更新、
添加或删除。
这并不表示数据损坏，但报告的差异可能会令人困惑，并且可能与在文件系统上
执行的操作不直接对应。
未更改时间戳的原地文件修改
SnapRAID 通过比较文件大小和修改时间戳（mtime）来检测文件修改。
@ -1638,6 +1627,23 @@ Name{number}
如果部分 `fix` 报告了无法恢复的数据，请在尝试另一次恢复之前删除受影响的
文件或对其重命名，或者手动验证其内容。
NTFS 硬链接与排除的路径
在 NTFS 上，目录条目会为每个硬链接单独缓存文件大小和时间戳。
当通过其中一个链接修改文件时，指向同一文件的其他链接的目录条目
可能会保留过时的元数据，直到它们被访问为止。
如果在扫描过程中遇到同一文件的至少两个硬链接，SnapRAID 会自动
检测并规范化这种情况。但是，如果仅扫描了一个硬链接，而其他硬链接
被过滤器排除或位于数据磁盘路径之外，SnapRAID 将无法检测到 inode 冲突，
并会依赖单个可见链接的缓存元数据。
因此，通过被排除或外部的硬链接所做的修改，在操作系统刷新所包含链接
的元数据之前（例如通过该路径访问或打开文件时），可能会被 SnapRAID 忽略。
为避免此限制，请避免通过已从 SnapRAID 中排除的硬链接来修改受保护
的文件，或者确保文件的所有硬链接都包含在扫描中，以便 SnapRAID 可以
对它们进行规范化。
翻译 (Translation)
本文档是英文手册的自动翻译。
请参阅英文手册以获取权威版本。

40
doc/snapraid-zh.txt
View file

@ -1707,20 +1707,7 @@ SnapRAID 在扫描数据磁盘时不会跨越文件系统、挂载点或子卷
启用文件系统快照时，请勿在数据磁盘内放置嵌套挂载点或 bind 挂载。
16.3 硬链接
--------
SnapRAID 将一个硬链接标识为原始文件，并将其他硬链接表示为对它的引用。
选择哪个链接作为原始文件取决于扫描目录条目的顺序。
如果此顺序发生更改（例如在重命名、恢复文件或重新创建目录之后），
即使链接的文件仍然表示相同的数据，“diff” 也可能会报告表面上的移动、更新、
添加或删除。
这并不表示数据损坏，但报告的差异可能会令人困惑，并且可能与在文件系统上
执行的操作不直接对应。
16.4 未更改时间戳的原地文件修改
16.3 未更改时间戳的原地文件修改
------------------
SnapRAID 通过比较文件大小和修改时间戳（mtime）来检测文件修改。
@ -1731,7 +1718,7 @@ SnapRAID 通过比较文件大小和修改时间戳（mtime）来检测文件修
为确保 SnapRAID 识别此类更改，请更新文件的修改时间戳（例如使用 “touch” 实用程序）。
否则，该差异仅在后续的 “scrub” 或 “check” 期间作为哈希不匹配被检测到。
16.5 Windows 非 ASCII 大小写匹配
16.4 Windows 非 ASCII 大小写匹配
--------------------------
SnapRAID 在所有平台上均使用标准且可预测的 UTF-8 编码，仅对 ASCII 字符进行
@ -1748,7 +1735,7 @@ Unicode 文件名之间强制实行不区分大小写。因此，Windows 掩盖
执着所致。为了防止因 Windows 的大小写折叠而产生差异，请在配置路径和过滤器中
始终为非 ASCII 字符指定准确的大小写。
16.6 无法恢复的文件后缀
16.5 无法恢复的文件后缀
--------------
当 `fix` 无法完全恢复损坏的文件时，它会通过在文件名后附加 `.unrecoverable`
@ -1766,7 +1753,7 @@ Unicode 文件名之间强制实行不区分大小写。因此，Windows 掩盖
请避免对常规文件使用 `.unrecoverable` 扩展名，并确保在配置中包含
`exclude *.unrecoverable`，以防止在奇偶校验数据集中跟踪此类文件。
16.7 部分 fix 恢复
16.6 部分 fix 恢复
--------------
当使用 `-S, --start` 或 `-B, --count` 限制 `fix` 时，
@ -1783,6 +1770,25 @@ SnapRAID 仅对选定的块进行操作，而不执行文件级别的最终化
如果部分 `fix` 报告了无法恢复的数据，请在尝试另一次恢复之前删除受影响的
文件或对其重命名，或者手动验证其内容。
16.7 NTFS 硬链接与排除的路径
-------------------
在 NTFS 上，目录条目会为每个硬链接单独缓存文件大小和时间戳。
当通过其中一个链接修改文件时，指向同一文件的其他链接的目录条目
可能会保留过时的元数据，直到它们被访问为止。
如果在扫描过程中遇到同一文件的至少两个硬链接，SnapRAID 会自动
检测并规范化这种情况。但是，如果仅扫描了一个硬链接，而其他硬链接
被过滤器排除或位于数据磁盘路径之外，SnapRAID 将无法检测到 inode 冲突，
并会依赖单个可见链接的缓存元数据。
因此，通过被排除或外部的硬链接所做的修改，在操作系统刷新所包含链接
的元数据之前（例如通过该路径访问或打开文件时），可能会被 SnapRAID 忽略。
为避免此限制，请避免通过已从 SnapRAID 中排除的硬链接来修改受保护
的文件，或者确保文件的所有硬链接都包含在扫描中，以便 SnapRAID 可以
对它们进行规范化。
17 翻译 (TRANSLATION)
===================

34
doc/snapraid.1
View file

@ -2308,19 +2308,6 @@ visible.
.PP
Do not place nested mount points or bind mounts inside data disks when
filesystem snapshots are enabled.
.SS Hard links
SnapRAID identifies one hard link as the original file and represents the
other hard links as references to it. Which link is selected as the original
file depends on the order in which directory entries are scanned.
.PP
If this order changes, for example after files are renamed, restored, or
directories are recreated, \[dq]diff\[dq] may report apparent moves, updates,
additions, or removals even when the hard\-linked files still represent the
same data.
.PP
This does not indicate data corruption, but the reported differences may be
confusing and may not correspond directly to the filesystem operations that
were performed.
.SS In\-place file modifications without timestamp changes
SnapRAID detects file modifications by comparing file sizes and
modification timestamps (mtime).
@ -2389,6 +2376,27 @@ The \`\-S\` and \`\-B\` options are intended only for advanced manual recovery,
typically after a normal \`fix\` has failed. If a partial \`fix\` reports
unrecoverable data, remove or rename the affected files before attempting
another recovery, or verify their contents manually.
.SS NTFS hard links and excluded paths
On NTFS, directory entries cache file size and timestamps independently
for each hard link. When a file is modified through one link, the directory
entries of other links pointing to the same file may retain stale metadata
until they are accessed.
.PP
SnapRAID automatically detects and normalizes this condition whenever at
least two hard links to the same file are encountered during a scan.
However, if only one hard link is scanned while the others are excluded by
filters or reside outside the data disk path, SnapRAID cannot detect the
inode collision and relies on the cached metadata of the single visible
link.
.PP
Consequently, modifications made through an excluded or external hard link
may go unnoticed by SnapRAID until the metadata of the included link is
refreshed by the operating system (such as when the file is accessed or
opened through that path).
.PP
To avoid this limitation, avoid modifying protected files through hard
links that are excluded from SnapRAID, or ensure that all hard links to a
file are included in the scan so SnapRAID can normalize them.
.SH COPYRIGHT
This file is Copyright (C) 2026 Andrea Mazzoleni
.SH SEE ALSO

36
doc/snapraid.d
View file

@ -1806,20 +1806,6 @@ Known Issues
Do not place nested mount points or bind mounts inside data disks when
filesystem snapshots are enabled.
Hard links
SnapRAID identifies one hard link as the original file and represents the
other hard links as references to it. Which link is selected as the original
file depends on the order in which directory entries are scanned.
If this order changes, for example after files are renamed, restored, or
directories are recreated, "diff" may report apparent moves, updates,
additions, or removals even when the hard-linked files still represent the
same data.
This does not indicate data corruption, but the reported differences may be
confusing and may not correspond directly to the filesystem operations that
were performed.
In-place file modifications without timestamp changes
SnapRAID detects file modifications by comparing file sizes and
modification timestamps (mtime).
@ -1892,6 +1878,28 @@ Known Issues
unrecoverable data, remove or rename the affected files before attempting
another recovery, or verify their contents manually.
NTFS hard links and excluded paths
On NTFS, directory entries cache file size and timestamps independently
for each hard link. When a file is modified through one link, the directory
entries of other links pointing to the same file may retain stale metadata
until they are accessed.
SnapRAID automatically detects and normalizes this condition whenever at
least two hard links to the same file are encountered during a scan.
However, if only one hard link is scanned while the others are excluded by
filters or reside outside the data disk path, SnapRAID cannot detect the
inode collision and relies on the cached metadata of the single visible
link.
Consequently, modifications made through an excluded or external hard link
may go unnoticed by SnapRAID until the metadata of the included link is
refreshed by the operating system (such as when the file is accessed or
opened through that path).
To avoid this limitation, avoid modifying protected files through hard
links that are excluded from SnapRAID, or ensure that all hard links to a
file are included in the scan so SnapRAID can normalize them.
Copyright
This file is Copyright (C) 2026 Andrea Mazzoleni

48
doc/snapraid.txt
View file

@ -1941,23 +1941,7 @@ visible.
Do not place nested mount points or bind mounts inside data disks when
filesystem snapshots are enabled.
16.3 Hard links
---------------
SnapRAID identifies one hard link as the original file and represents the
other hard links as references to it. Which link is selected as the original
file depends on the order in which directory entries are scanned.
If this order changes, for example after files are renamed, restored, or
directories are recreated, "diff" may report apparent moves, updates,
additions, or removals even when the hard-linked files still represent the
same data.
This does not indicate data corruption, but the reported differences may be
confusing and may not correspond directly to the filesystem operations that
were performed.
16.4 In-place file modifications without timestamp changes
16.3 In-place file modifications without timestamp changes
----------------------------------------------------------
SnapRAID detects file modifications by comparing file sizes and
@ -1972,7 +1956,7 @@ modification timestamp (for example, with the "touch" utility).
Otherwise, the difference will only be detected as a hash mismatch
during a subsequent "scrub" or "check".
16.5 Windows non-ASCII case matching
16.4 Windows non-ASCII case matching
------------------------------------
SnapRAID uses standard, predictable UTF-8 encoding across all platforms,
@ -1993,7 +1977,7 @@ filenames and its insistence on case-insensitive aliasing. To prevent
discrepancies arising from Windows's case folding, always specify the
exact case for any non-ASCII characters in configuration paths and filters.
16.6 Unrecoverable files suffix
16.5 Unrecoverable files suffix
-------------------------------
When `fix` cannot fully recover a damaged file, it quarantines it by
@ -2015,7 +1999,7 @@ Avoid using the `.unrecoverable` extension for regular files, and ensure
that `exclude *.unrecoverable` is included in your configuration to
prevent such files from being tracked in the parity dataset.
16.7 Partial fix recovery
16.6 Partial fix recovery
-------------------------
When `fix` is restricted using `-S, --start` or `-B, --count`,
@ -2037,6 +2021,30 @@ typically after a normal `fix` has failed. If a partial `fix` reports
unrecoverable data, remove or rename the affected files before attempting
another recovery, or verify their contents manually.
16.7 NTFS hard links and excluded paths
---------------------------------------
On NTFS, directory entries cache file size and timestamps independently
for each hard link. When a file is modified through one link, the directory
entries of other links pointing to the same file may retain stale metadata
until they are accessed.
SnapRAID automatically detects and normalizes this condition whenever at
least two hard links to the same file are encountered during a scan.
However, if only one hard link is scanned while the others are excluded by
filters or reside outside the data disk path, SnapRAID cannot detect the
inode collision and relies on the cached metadata of the single visible
link.
Consequently, modifications made through an excluded or external hard link
may go unnoticed by SnapRAID until the metadata of the included link is
refreshed by the operating system (such as when the file is accessed or
opened through that path).
To avoid this limitation, avoid modifying protected files through hard
links that are excluded from SnapRAID, or ensure that all hard links to a
file are included in the scan so SnapRAID can normalize them.
17 COPYRIGHT
============