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

Make .unrecoverable a persistent one-way recovery quarantine

Browse source
This commit is contained in:
Andrea Mazzoleni 2026-08-29 21:25:49 +02:00
parent 472c85a4fb
commit b9d0dcd173
46 changed files with 646 additions and 367 deletions
Download patch file Download diff file Expand all files Collapse all files

245
cmdline/check.c
View file

@ -188,16 +188,28 @@
* such data, but the containing file remains marked damaged and is kept under
* the .unrecoverable name instead of being reported as successfully recovered.
*
* Missing files are created as .unrecoverable from the beginning, and an
* existing .unrecoverable file is reused by later fix runs. This allows a
* recovery to proceed over multiple runs without exposing a partially rebuilt
* file under its final name.
* Missing files are created under their normal names. They are quarantined only
* if recovery produces data that cannot be certified as CURRENT.
*
* Promotion to the final file name is a file-level commit operation. It happens
* only after the complete file has been processed successfully, its metadata
* has been restored, and no block remains damaged. A partial -S/-B fix operates
* only at block level and therefore never performs this file-level promotion
* or other finalization.
* A later fix starts a new recovery attempt under the normal filename even if a
* previous .unrecoverable file exists. A previous quarantine cannot safely be
* reused as recovery input because it may contain an ambiguous recovered CHG.
* Such a CHG may have caused the file to be quarantined precisely because its
* CURRENT generation could not be proven. That provenance is runtime state and
* is not persisted in the .unrecoverable file. Reopening it in a later fix would
* make the CHG merely appear readable and could incorrectly accept it as CURRENT.
*
* The previous quarantine is therefore kept separate while the new recovery is
* in progress. If the new attempt succeeds completely, the obsolete quarantine
* is removed. If the new attempt also becomes unrecoverable, it replaces the
* previous quarantine.
*
* A quarantined file may be reopened later during the same fix run. In that case
* FILE_IS_QUARANTINED identifies it as belonging to the current failed recovery and
* handle_create() continues operating on its .unrecoverable file.
*
* A partial -S/-B fix operates only at block level and therefore never performs
* file-level finalization.
*/
/****************************************************************************/
@ -244,8 +256,10 @@ struct failed_struct {
* CURRENT contents, even though in some cases OLD and CURRENT may actually be
* identical.
*
* It is also set on a bad CHG when the current-parity strategy recovers a
* candidate that cannot be distinguished reliably from its OLD contents.
* This provenance exists only for the current check/fix run. It is not encoded
* in the recovered file itself, which is why a later fix cannot safely infer
* that a readable CHG from a previous .unrecoverable file represents CURRENT
* data.
*
* Out-of-date entries are excluded from hash validation. If an out-of-date
* block is also is_bad, fix may still preserve the recovered bytes as the best
@ -364,8 +378,9 @@ static int is_parity_matching(struct snapraid_state* state, unsigned diskmax, un
}
/**
* Try to recover the selected failed inputs and independently validate the
* reconstructed result.
* Try to recover the selected failed inputs and validate the reconstructed
* result using either a CURRENT hash or an additional RAID equation not used
* for reconstruction.
*
* Return:
* 0 if a recovery was successfully validated;
@ -410,8 +425,16 @@ static int repair_step(struct snapraid_state* state, int rehash, block_off_t pos
* recovery were themselves correct.
*
* If at least one failed input has a trustworthy CURRENT hash, recovered data
* can provide the independent validation. Otherwise one additional parity
* equation must be reserved exclusively for checking the candidate result.
* can provide independent validation. Otherwise one additional parity equation
* is reserved exclusively for checking the candidate result.
*
* The additional parity is an independent RAID equation, not an independent
* hash of the recovered data. The candidate is accepted only if the complete
* reconstructed block set satisfies this extra equation for the whole block.
* Therefore an accidental false match requires the data differences to satisfy
* the corresponding RAID relation at every byte position. Such correlated
* differences are possible in principle because RAID equations are linear, but
* are extremely unlikely for unrelated data corruption.
*/
has_hash = 0;
for (i = 0; i < failed_count; ++i) {
@ -1280,8 +1303,6 @@ static int file_post(struct snapraid_state* state, int fix, int partial, block_o
/* finish the fix process if it's the last block of the files */
if (fix) {
int was_unrecoverable;
if (handle[j].file != file) {
/* LCOV_EXCL_START */
log_fatal(EINTERNAL, "Internal inconsistency in file handle '%s' instead of '%s'\n",
@ -1289,13 +1310,11 @@ static int file_post(struct snapraid_state* state, int fix, int partial, block_o
os_abort();
/* LCOV_EXCL_STOP */
}
was_unrecoverable = handle[j].is_unrecoverable;
/*
* A partial fix operates only at block level. Reaching the last block of a
* file doesn't imply that the whole file was processed, so don't perform any
* file-level finalization, including marking it finished, promoting an
* .unrecoverable file, reporting it recovered, or restoring its timestamp.
* file-level finalization, including marking it finished, reporting its final
* status, or restoring its timestamp.
* This is intentional also when an explicit block range happens to cover all
* the parity blocks, to keep -S/-B behavior independent of the parity size.
*/
@ -1310,35 +1329,6 @@ static int file_post(struct snapraid_state* state, int fix, int partial, block_o
/* if the file is damaged, meaning that a fix failed */
if (file_flag_has(file, FILE_IS_DAMAGED)) {
char path[PATH_MAX];
char path_to[PATH_MAX];
pathprint(path, sizeof(path), "%s%s", disk->dir, file->sub);
pathprint(path_to, sizeof(path_to), "%s%s.unrecoverable", disk->dir, file->sub);
/* ensure to close the file before renaming */
ret = handle_close(&handle[j]);
if (ret != 0) {
/* LCOV_EXCL_START */
log_tag("%s:%" PRIu64 ":%s:%s: Close error. %s.\n", es(errno), i, disk->name, esc_tag(file->sub), strerror(errno));
log_fatal_errno(errno, disk->name);
return -1;
/* LCOV_EXCL_STOP */
}
/* a previous recovery is already quarantined */
if (!was_unrecoverable) {
ret = rename(path, path_to);
if (ret != 0) {
/* LCOV_EXCL_START */
log_fatal(errno, "Error renaming '%s%s'. %s.\n", disk->dir, file->sub, strerror(errno));
log_tag("%s:%" PRIu64 ":%s:%s: Rename error. %s.\n", es(errno), i, disk->name, esc_tag(file->sub), strerror(errno));
log_fatal_errno(errno, disk->name);
return -1;
/* LCOV_EXCL_STOP */
}
}
log_tag("status:unrecoverable:%s:%s\n", disk->name, esc_tag(file->sub));
msg_info("unrecoverable %s\n", fmt_term(disk, file->sub));
@ -1347,7 +1337,7 @@ static int file_post(struct snapraid_state* state, int fix, int partial, block_o
}
/* if the file is not fixed, meaning that it is untouched */
if (!file_flag_has(file, FILE_IS_FIXED) && !was_unrecoverable) {
if (!file_flag_has(file, FILE_IS_FIXED)) {
/* nothing to do, but close the file */
goto close_and_continue;
}
@ -1402,7 +1392,7 @@ static int file_post(struct snapraid_state* state, int fix, int partial, block_o
|| collide_file->mtime_sec != file->mtime_sec /* if the mtime is different, the collision is identified */
|| collide_file->mtime_nsec != file->mtime_nsec /* same for mtime_nsec */
) {
/* set the original modification time before promoting/renaming */
/* set the original modification time */
ret = handle_utime(&handle[j]);
if (ret == -1) {
/* LCOV_EXCL_START */
@ -1419,36 +1409,30 @@ static int file_post(struct snapraid_state* state, int fix, int partial, block_o
}
/*
* This rename is the file-level recovery commit point. Keep the file
* quarantined until every block and metadata was processed without error;
* promoting only after setting the timestamp ensures the final file is
* never exposed with incomplete data or provisional timestamp.
* Close the normal file before removing the previous quarantine.
* A delayed close error means that recovery is not yet successful,
* and the previous .unrecoverable file must remain available.
*/
if (was_unrecoverable) {
char path[PATH_MAX];
char path_from[PATH_MAX];
ret = handle_close(&handle[j]);
if (ret != 0) {
/* LCOV_EXCL_START */
log_tag("%s:%" PRIu64 ":%s:%s: Close error. %s.\n", es(errno), i, disk->name, esc_tag(file->sub), strerror(errno));
log_fatal_errno(errno, disk->name);
return -1;
/* LCOV_EXCL_STOP */
}
pathprint(path, sizeof(path), "%s%s", disk->dir, file->sub);
pathprint(path_from, sizeof(path_from), "%s%s.unrecoverable", disk->dir, file->sub);
ret = handle_close(&handle[j]);
if (ret != 0) {
/* LCOV_EXCL_START */
log_tag("%s:%" PRIu64 ":%s:%s: Close error. %s.\n", es(errno), i, disk->name, esc_tag(file->sub), strerror(errno));
log_fatal_errno(errno, disk->name);
return -1;
/* LCOV_EXCL_STOP */
}
ret = rename(path_from, path);
if (ret != 0) {
/* LCOV_EXCL_START */
log_fatal(errno, "Error renaming '%s'. %s.\n", path_from, strerror(errno));
log_tag("%s:%" PRIu64 ":%s:%s: Rename error. %s.\n", es(errno), i, disk->name, esc_tag(file->sub), strerror(errno));
log_fatal_errno(errno, disk->name);
return -1;
/* LCOV_EXCL_STOP */
}
/*
* The normal file has now been completely recovered, finalized, and closed.
* Remove any quarantine left by an earlier failed recovery attempt.
*/
ret = handle_unrecoverable_remove(&handle[j], file);
if (ret != 0) {
/* LCOV_EXCL_START */
log_tag("%s:%" PRIu64 ":%s:%s: Remove unrecoverable error. %s.\n", es(errno), i, disk->name, esc_tag(file->sub), strerror(errno));
log_fatal_errno(errno, disk->name);
return -1;
/* LCOV_EXCL_STOP */
}
log_tag("status:recovered:%s:%s\n", disk->name, esc_tag(file->sub));
@ -1891,6 +1875,8 @@ static int state_check_process(struct snapraid_state* state, int fix, struct sna
/* LCOV_EXCL_STOP */
}
file_flag_set(file, FILE_IS_FIXED);
log_tag("fixed:%" PRIu64 ":%s:%s: Fixed size\n", i, disk->name, esc_tag(file->sub));
++recovered_error;
}
@ -1957,10 +1943,11 @@ static int state_check_process(struct snapraid_state* state, int fix, struct sna
* against block->hash, as a match would only identify the old data
* and a mismatch would not prove that the current data is correct.
*
* This also intentionally applies to data reused from a previous
* multistep fix through an .unrecoverable file: already readable CHG
* data is preserved, while fix attempts to recover only missing or
* unreadable blocks.
* This assumption applies only to data belonging to the current recovery
* attempt. A CHG from a previous .unrecoverable file cannot safely be reused:
* it may itself be an ambiguous recovery result whose CURRENT generation was
* not proven. Once persisted, that provenance cannot be inferred from the
* bytes alone.
*/
failed[failed_count].is_bad = 0; /* we assume the CHG block correct */
failed[failed_count].is_outofdate = 0;
@ -2084,8 +2071,33 @@ static int state_check_process(struct snapraid_state* state, int fix, struct sna
/* keep track of damaged files */
for (j = 0; j < failed_count; ++j) {
if (failed[j].is_bad)
file_flag_set(failed[j].file, FILE_IS_DAMAGED);
if (!failed[j].is_bad)
continue;
file_flag_set(failed[j].file, FILE_IS_DAMAGED);
/*
* Persist the unrecoverable state immediately for a full fix.
* Quarantine is a file-level operation because it renames the whole file.
* A partial -S/-B fix operates only at block level, so keep FILE_IS_DAMAGED
* but leave the file under its normal name when partial is set.
*/
if (fix
&& !file_flag_has(failed[j].file, FILE_IS_EXCLUDED)
&& !(state->opt.syncedonly && file_flag_has(failed[j].file, FILE_IS_UNSYNCED))
&& !partial
) {
ret = handle_quarantine(failed[j].handle, failed[j].file, state->file_mode);
if (ret == -1) {
/* LCOV_EXCL_START */
log_tag("%s:%" PRIu64 ":%s:%s: Quarantine error. %s.\n", es(errno), i, failed[j].disk->name, esc_tag(failed[j].file->sub), strerror(errno));
log_fatal_errno(errno, failed[j].disk->name);
log_fatal(errno, "Stopping at block %" PRIu64 "\n", i);
++unrecoverable_error;
goto bail;
/* LCOV_EXCL_STOP */
}
}
}
} else {
/*
@ -2150,32 +2162,70 @@ static int state_check_process(struct snapraid_state* state, int fix, struct sna
/*
* Write the best recovered candidate even when it is out-of-date. Such data
* may still be useful to the user or to a later multistep recovery.
*
* An out-of-date write is not considered a successful fix: the file is marked
* damaged below and file_post() keeps or moves it to .unrecoverable instead
* of promoting it as recovered.
*/
/*
* An out-of-date candidate is useful best-effort data,
* but it cannot be certified as the required CURRENT
* contents. Persist this fact before modifying the file
* so that a SIGKILL cannot leave unproven recovered data
* under the normal filename.
*/
if (failed[j].is_outofdate) {
file_flag_set(failed[j].file, FILE_IS_DAMAGED);
/*
* Quarantine is a file-level operation because it renames the whole file.
* A partial -S/-B fix may still write the selected best-effort block, but it
* must not rename or quarantine the complete file outside the requested range.
*/
if (!partial) {
ret = handle_quarantine(failed[j].handle, failed[j].file, state->file_mode);
if (ret == -1) {
/* LCOV_EXCL_START */
log_tag("%s:%" PRIu64 ":%s:%s: Quarantine error. %s.\n", es(errno), i, failed[j].disk->name, esc_tag(failed[j].file->sub), strerror(errno));
log_fatal_errno(errno, failed[j].disk->name);
log_fatal(errno, "Stopping at block %" PRIu64 "\n", i);
++unrecoverable_error;
goto bail;
/* LCOV_EXCL_STOP */
}
}
}
ret = handle_write(failed[j].handle, failed[j].file_pos, buffer[failed[j].index], state->block_size);
if (ret == -1) {
/* LCOV_EXCL_START */
log_tag("%s:%" PRIu64 ":%s:%s: Write error. %s.\n", es(errno), i, failed[j].disk->name, esc_tag(failed[j].file->sub), strerror(errno));
log_fatal_errno(errno, failed[j].disk->name);
log_fatal(errno, "Stopping at block %" PRIu64 "\n", i);
int saved_errno = errno;
/* mark the file as damaged */
file_flag_set(failed[j].file, FILE_IS_DAMAGED);
/*
* Quarantine is a file-level operation because it renames the whole file.
* A partial -S/-B fix must leave the complete file under its normal name even
* when a selected block write fails; FILE_IS_DAMAGED still records the failure.
*/
if (!partial) {
ret = handle_quarantine(failed[j].handle, failed[j].file, state->file_mode);
if (ret == -1) {
log_tag("%s:%" PRIu64 ":%s:%s: Quarantine error. %s.\n", es(errno), i, failed[j].disk->name, esc_tag(failed[j].file->sub), strerror(errno));
log_fatal_errno(errno, failed[j].disk->name);
}
}
errno = saved_errno;
log_tag("%s:%" PRIu64 ":%s:%s: Write error. %s.\n", es(errno), i, failed[j].disk->name, esc_tag(failed[j].file->sub), strerror(errno));
log_fatal_errno(errno, failed[j].disk->name);
log_fatal(errno, "Stopping at block %" PRIu64 "\n", i);
++unrecoverable_error;
goto bail;
/* LCOV_EXCL_STOP */
}
/* if we are not sure that the recovered content is uptodate */
if (failed[j].is_outofdate) {
/* mark the file as damaged */
file_flag_set(failed[j].file, FILE_IS_DAMAGED);
if (failed[j].is_outofdate)
continue;
}
/*
* Mark the file as containing some fixes
@ -3003,4 +3053,3 @@ int state_check(struct snapraid_state* state, int fix, block_off_t blockstart, b
return 0;
}

6
cmdline/elem.h
View file

@ -261,6 +261,12 @@ struct snapraid_block {
*/
#define FILE_IS_UNSYNCED 0x100
/**
* If the current recovery attempt was actually moved to the .unrecoverable name.
* It's used only in fix to track the physical quarantine state independently
* from FILE_IS_DAMAGED.
*/
#define FILE_IS_QUARANTINED 0x200
/**
* The file is deleted.

209
cmdline/handle.c
View file

@ -14,6 +14,8 @@ int handle_create(struct snapraid_handle* handle, struct snapraid_file* file, in
{
int ret;
int flags;
char path[PATH_MAX];
char path_unrecoverable[PATH_MAX];
/* if it's the same file, and already opened, nothing to do */
if (handle->file == file && handle->f != -1) {
@ -21,9 +23,11 @@ int handle_create(struct snapraid_handle* handle, struct snapraid_file* file, in
}
advise_init(&handle->advise, mode);
pathprint(handle->path, sizeof(handle->path), "%s%s", handle->disk->dir, file->sub);
ret = mkancestor(handle->path);
pathprint(path, sizeof(path), "%s%s", handle->disk->dir, file->sub);
pathprint(path_unrecoverable, sizeof(path_unrecoverable), "%s.unrecoverable", path);
ret = mkancestor(path);
if (ret != 0) {
/* LCOV_EXCL_START */
return -1;
@ -32,7 +36,6 @@ int handle_create(struct snapraid_handle* handle, struct snapraid_file* file, in
/* initial values, changed later if required */
handle->created = 0;
handle->is_unrecoverable = 0;
handle->readonly_errno = 0;
/*
@ -42,63 +45,67 @@ int handle_create(struct snapraid_handle* handle, struct snapraid_file* file, in
*/
flags = O_BINARY | O_NOFOLLOW | advise_flags(&handle->advise);
/* open for read write */
handle->f = open(handle->path, flags | O_RDWR);
/* if failed for missing write permission */
if (handle->f == -1 && (errno == EACCES || errno == EROFS)) {
int saved_errno = errno;
/* open for read-only */
handle->f = open(handle->path, flags | O_RDONLY);
if (handle->f != -1) {
handle->readonly_errno = saved_errno;
}
}
/* if failed for missing file */
if (handle->f == -1 && errno == ENOENT) {
char path_unrecoverable[PATH_MAX];
/* check if exists a .unrecoverable copy */
pathprint(path_unrecoverable, sizeof(path_unrecoverable), "%s.unrecoverable", handle->path);
/*
* Open a previous recovery directly as .unrecoverable, keeping it
* quarantined until the whole file is processed successfully. Promoting
* it now could expose an incomplete or unverified file if this fix aborts
* or fails again. Reuse it for a multistep fix, preserving readable CHG
* blocks because their current hash is not available.
*/
/*
* If this recovery attempt was actually quarantined during the current fix run,
* continue operating on its .unrecoverable copy.
*
* FILE_IS_QUARANTINED is runtime state and is not carried to a later fix.
* FILE_IS_DAMAGED alone does not imply that the file was physically quarantined,
* because some fix modes deliberately keep damaged files under their normal name.
*/
if (file_flag_has(file, FILE_IS_QUARANTINED)) {
handle->f = open(path_unrecoverable, flags | O_RDWR);
if (handle->f != -1) {
handle->is_unrecoverable = 1;
pathcpy(handle->path, sizeof(handle->path), path_unrecoverable);
} else if (errno == ENOENT) {
/*
* Create missing file as .unrecoverable so that an interruption or
* crash (e.g. SIGKILL) during recovery never leaves a partially recovered
* file visible under its final name.
*/
handle->f = open(path_unrecoverable, flags | O_RDWR | O_CREAT | O_EXCL, 0600);
/* if failed for missing write permission */
if (handle->f == -1 && (errno == EACCES || errno == EROFS)) {
int saved_errno = errno;
/* open for read-only */
handle->f = open(path_unrecoverable, flags | O_RDONLY);
if (handle->f != -1) {
handle->is_unrecoverable = 1;
pathcpy(handle->path, sizeof(handle->path), path_unrecoverable);
handle->readonly_errno = saved_errno;
}
}
pathcpy(handle->path, sizeof(handle->path), path_unrecoverable);
} else {
/*
* Start every recovery attempt from the normal filename.
*
* Do not reuse an .unrecoverable file left by a previous fix. It may
* contain recovered CHG blocks whose CURRENT generation could not be
* proven. That ambiguity is runtime state and is not persisted with
* the file. Reopening such a file in a later fix would make those CHG
* blocks appear merely readable and could incorrectly treat them as
* valid CURRENT data.
*
* A previous .unrecoverable file is therefore kept only as the
* best-effort result of that recovery attempt, not as input for a
* subsequent one.
*/
handle->f = open(path, flags | O_RDWR);
/* if failed for missing write permission */
if (handle->f == -1 && (errno == EACCES || errno == EROFS)) {
int saved_errno = errno;
/* open for read-only */
handle->f = open(path, flags | O_RDONLY);
if (handle->f != -1) {
handle->readonly_errno = saved_errno;
}
}
/* if failed for missing file */
if (handle->f == -1 && errno == ENOENT) {
handle->f = open(path, flags | O_RDWR | O_CREAT | O_EXCL, 0600);
if (handle->f != -1) {
handle->created = 1;
} else if (errno == EEXIST) {
/* if created concurrently, reopen safely */
handle->f = open(path_unrecoverable, flags | O_RDWR);
if (handle->f != -1) {
handle->is_unrecoverable = 1;
pathcpy(handle->path, sizeof(handle->path), path_unrecoverable);
} else {
pathcpy(handle->path, sizeof(handle->path), path_unrecoverable);
}
} else {
pathcpy(handle->path, sizeof(handle->path), path_unrecoverable);
handle->f = open(path, flags | O_RDWR);
}
} else {
/* report the path that failed to open */
pathcpy(handle->path, sizeof(handle->path), path_unrecoverable);
}
pathcpy(handle->path, sizeof(handle->path), path);
}
if (handle->f == -1) {
@ -137,6 +144,95 @@ int handle_create(struct snapraid_handle* handle, struct snapraid_file* file, in
return 0;
}
/**
* Move an opened file to its persistent .unrecoverable name.
*/
int handle_quarantine(struct snapraid_handle* handle, struct snapraid_file* file, int mode)
{
char path[PATH_MAX];
char path_to[PATH_MAX];
int ret;
(void)mode;
/* already quarantined during the current fix run */
if (file_flag_has(file, FILE_IS_QUARANTINED))
return 0;
/* mark this recovery attempt as damaged */
file_flag_set(file, FILE_IS_DAMAGED);
pathprint(path, sizeof(path), "%s%s", handle->disk->dir, file->sub);
pathprint(path_to, sizeof(path_to), "%s%s.unrecoverable", handle->disk->dir, file->sub);
#ifdef _WIN32
/*
* Windows may not allow renaming an opened file. Close it before
* replacing the previous quarantine and renaming the current file.
*/
ret = handle_close(handle);
if (ret != 0)
return -1;
ret = rename(path, path_to);
if (ret != 0) {
/* LCOV_EXCL_START */
log_error(errno, "Error renaming file '%s' to '%s'. %s.\n", path, path_to, strerror(errno));
return -1;
/* LCOV_EXCL_STOP */
}
file_flag_set(file, FILE_IS_QUARANTINED);
/*
* FILE_IS_QUARANTINED is set, so handle_create() reopens the
* .unrecoverable file belonging to the current recovery attempt.
*/
ret = handle_create(handle, file, mode);
if (ret != 0)
return -1;
#else
/*
* POSIX rename() atomically replaces an existing destination file.
* The opened descriptor continues to reference the renamed inode, so
* no close/reopen is required.
*/
ret = rename(path, path_to);
if (ret != 0) {
/* LCOV_EXCL_START */
log_error(errno, "Error renaming file '%s' to '%s'. %s.\n", path, path_to, strerror(errno));
return -1;
/* LCOV_EXCL_STOP */
}
file_flag_set(file, FILE_IS_QUARANTINED);
pathcpy(handle->path, sizeof(handle->path), path_to);
#endif
return 0;
}
/**
* Remove an .unrecoverable file left by a previous recovery attempt.
*/
int handle_unrecoverable_remove(struct snapraid_handle* handle, struct snapraid_file* file)
{
char path[PATH_MAX];
int ret;
pathprint(path, sizeof(path), "%s%s.unrecoverable", handle->disk->dir, file->sub);
ret = remove(path);
if (ret != 0 && errno != ENOENT) {
/* LCOV_EXCL_START */
log_error(errno, "Error removing file '%s'. %s.\n", path, strerror(errno));
return -1;
/* LCOV_EXCL_STOP */
}
return 0;
}
int handle_truncate(struct snapraid_handle* handle, struct snapraid_file* file)
{
int ret;
@ -187,7 +283,6 @@ int handle_open(struct snapraid_handle* handle, struct snapraid_file* file, int
/* for sure not created */
handle->created = 0;
handle->is_unrecoverable = 0;
handle->readonly_errno = 0;
/*
@ -255,7 +350,6 @@ int handle_close(struct snapraid_handle* handle)
handle->file = 0;
handle->f = -1;
handle->physical_reach_size = 0;
handle->is_unrecoverable = 0;
return -1;
/* LCOV_EXCL_STOP */
}
@ -265,7 +359,6 @@ int handle_close(struct snapraid_handle* handle)
handle->file = 0;
handle->f = -1;
handle->physical_reach_size = 0;
handle->is_unrecoverable = 0;
handle->readonly_errno = 0;
return 0;
@ -459,7 +552,6 @@ struct snapraid_handle* handle_mapping(struct snapraid_state* state, unsigned* h
handle[j].file = 0;
handle[j].f = -1;
handle[j].physical_reach_size = 0;
handle[j].is_unrecoverable = 0;
handle[j].readonly_errno = 0;
handle[j].bw = 0;
}
@ -490,4 +582,3 @@ struct snapraid_handle* handle_mapping(struct snapraid_state* state, unsigned* h
*handlemax = size;
return handle;
}

25
cmdline/handle.h
View file

@ -30,22 +30,36 @@ struct snapraid_handle {
*/
data_off_t physical_reach_size;
int created; /**< If the file was created, otherwise it was already existing. */
int is_unrecoverable; /**< If the open descriptor refers to the .unrecoverable path. */
int readonly_errno; /**< Non-zero if opened read-only as fallback. */
struct snapraid_bw* bw; /**< Context for bandwidth limiting. */
};
/**
* Create a file.
* The file is created if missing, and opened with write access.
* If the file is created, the handle->created is set.
* If a previous .unrecoverable file is opened, the handle->is_unrecoverable is set.
* Create or reopen a recovery file.
* A new recovery attempt always uses the normal filename, even if a previous .unrecoverable file exists.
* FILE_IS_QUARANTINED determines whether the .unrecoverable filename is opened in the current run.
* If the normal file is created, the handle->created is set.
* The initial size of the file is stored in the file->st struct.
* If the file cannot be opened for write access, it's opened with read-only access.
* The read-only access works only if the file has already the correct size and doesn't need to be modified.
*/
int handle_create(struct snapraid_handle* handle, struct snapraid_file* file, int mode);
/**
* Move an opened file to its persistent .unrecoverable name.
* A previous .unrecoverable from an older recovery attempt is replaced.
* If already quarantined in the current run, do nothing.
* On error, log the failure and return -1 with errno set.
*/
int handle_quarantine(struct snapraid_handle* handle, struct snapraid_file* file, int mode);
/**
* Remove an .unrecoverable file left by a previous recovery attempt.
* A missing .unrecoverable file is not an error.
* On error, log the failure and return -1 with errno set.
*/
int handle_unrecoverable_remove(struct snapraid_handle* handle, struct snapraid_file* file);
/**
* Truncate a file if required.
*/
@ -86,4 +100,3 @@ int handle_utime(struct snapraid_handle* handle);
struct snapraid_handle* handle_mapping(struct snapraid_state* state, unsigned* diskmax);
#endif

16
doc/snapraid-de.1
View file

@ -2490,15 +2490,19 @@ Wenn \`fix\` eine beschädigte Datei nicht vollständig wiederherstellen kann,
wird sie unter Quarantäne gestellt, indem die Erweiterung \`.unrecoverable\`
an ihren Namen angehängt wird.
.PP
Umgekehrt gilt: Wenn eine fehlende Datei wiederhergestellt wird und bereits
eine entsprechende \`.unrecoverable\`\-Datei vorhanden ist, nimmt SnapRAID an,
dass es sich um das Ergebnis einer früheren unvollständigen Wiederherstellung
handelt, und setzt das Schreiben direkt in dieser Datei fort.
Wenn ein späterer \`fix\`\-Vorgang die Wiederherstellung wiederholt, erstellt
er eine neue Datei unter dem normalen Dateinamen und behält die alte
\`.unrecoverable\`\-Datei bei, während die Wiederherstellung läuft. Wenn der
erneute Versuch fehlschlägt, ersetzt das neue fehlgeschlagene Ergebnis die
alte Quarantäne. Wenn der erneute Versuch vollständig erfolgreich ist, löscht
SnapRAID die veraltete \`.unrecoverable\`\-Datei. Eine Quarantänedatei wird
niemals wieder in den normalen Dateinamen umbenannt.
.PP
Da SnapRAID Quarantänedateien ausschließlich anhand ihres Dateinamens
identifiziert, kann jede bereits vorhandene Datei, die zufällig die Endung
\`.unrecoverable\` verwendet, abgeschnitten, überschrieben oder ersetzt werden,
wenn ihr Basisname mit einer gerade wiederherzustellenden Datei übereinstimmt.
\`.unrecoverable\` verwendet, abgeschnitten, überschrieben, ersetzt oder gelöscht
werden, wenn ihr Basisname mit einer gerade wiederherzustellenden Datei
übereinstimmt.
.PP
Vermeiden Sie die Verwendung der Erweiterung \`.unrecoverable\` für reguläre
Dateien und stellen Sie sicher, dass \`exclude *.unrecoverable\` in Ihrer

16
doc/snapraid-de.d
View file

@ -1980,15 +1980,19 @@ Bekannte Probleme (Known Issues)
wird sie unter Quarantäne gestellt, indem die Erweiterung `.unrecoverable`
an ihren Namen angehängt wird.
Umgekehrt gilt: Wenn eine fehlende Datei wiederhergestellt wird und bereits
eine entsprechende `.unrecoverable`-Datei vorhanden ist, nimmt SnapRAID an,
dass es sich um das Ergebnis einer früheren unvollständigen Wiederherstellung
handelt, und setzt das Schreiben direkt in dieser Datei fort.
Wenn ein späterer `fix`-Vorgang die Wiederherstellung wiederholt, erstellt
er eine neue Datei unter dem normalen Dateinamen und behält die alte
`.unrecoverable`-Datei bei, während die Wiederherstellung läuft. Wenn der
erneute Versuch fehlschlägt, ersetzt das neue fehlgeschlagene Ergebnis die
alte Quarantäne. Wenn der erneute Versuch vollständig erfolgreich ist, löscht
SnapRAID die veraltete `.unrecoverable`-Datei. Eine Quarantänedatei wird
niemals wieder in den normalen Dateinamen umbenannt.
Da SnapRAID Quarantänedateien ausschließlich anhand ihres Dateinamens
identifiziert, kann jede bereits vorhandene Datei, die zufällig die Endung
`.unrecoverable` verwendet, abgeschnitten, überschrieben oder ersetzt werden,
wenn ihr Basisname mit einer gerade wiederherzustellenden Datei übereinstimmt.
`.unrecoverable` verwendet, abgeschnitten, überschrieben, ersetzt oder gelöscht
werden, wenn ihr Basisname mit einer gerade wiederherzustellenden Datei
übereinstimmt.
Vermeiden Sie die Verwendung der Erweiterung `.unrecoverable` für reguläre
Dateien und stellen Sie sicher, dass `exclude *.unrecoverable` in Ihrer

16
doc/snapraid-de.txt
View file

@ -2123,15 +2123,19 @@ Wenn `fix` eine beschädigte Datei nicht vollständig wiederherstellen kann,
wird sie unter Quarantäne gestellt, indem die Erweiterung `.unrecoverable`
an ihren Namen angehängt wird.
Umgekehrt gilt: Wenn eine fehlende Datei wiederhergestellt wird und bereits
eine entsprechende `.unrecoverable`-Datei vorhanden ist, nimmt SnapRAID an,
dass es sich um das Ergebnis einer früheren unvollständigen Wiederherstellung
handelt, und setzt das Schreiben direkt in dieser Datei fort.
Wenn ein späterer `fix`-Vorgang die Wiederherstellung wiederholt, erstellt
er eine neue Datei unter dem normalen Dateinamen und behält die alte
`.unrecoverable`-Datei bei, während die Wiederherstellung läuft. Wenn der
erneute Versuch fehlschlägt, ersetzt das neue fehlgeschlagene Ergebnis die
alte Quarantäne. Wenn der erneute Versuch vollständig erfolgreich ist, löscht
SnapRAID die veraltete `.unrecoverable`-Datei. Eine Quarantänedatei wird
niemals wieder in den normalen Dateinamen umbenannt.
Da SnapRAID Quarantänedateien ausschließlich anhand ihres Dateinamens
identifiziert, kann jede bereits vorhandene Datei, die zufällig die Endung
`.unrecoverable` verwendet, abgeschnitten, überschrieben oder ersetzt werden,
wenn ihr Basisname mit einer gerade wiederherzustellenden Datei übereinstimmt.
`.unrecoverable` verwendet, abgeschnitten, überschrieben, ersetzt oder gelöscht
werden, wenn ihr Basisname mit einer gerade wiederherzustellenden Datei
übereinstimmt.
Vermeiden Sie die Verwendung der Erweiterung `.unrecoverable` für reguläre
Dateien und stellen Sie sicher, dass `exclude *.unrecoverable` in Ihrer

13
doc/snapraid-es.1
View file

@ -2444,14 +2444,17 @@ los caracteres no ASCII en las rutas de configuración y filtros.
Cuando \`fix\` no puede recuperar por completo un archivo dañado, lo pone en
cuarentena añadiendo la extensión \`.unrecoverable\` a su nombre.
.PP
Por el contrario, si se está recuperando un archivo que falta y ya existe
un archivo \`.unrecoverable\` correspondiente, SnapRAID asume que es el
resultado de una recuperación incompleta anterior y reanuda la escritura en él.
Si un \`fix\` posterior reintenta la recuperación, crea un nuevo archivo con el
nombre de archivo normal y conserva el antiguo archivo \`.unrecoverable\`
mientras la recuperación está en curso. Si el reintento falla, el nuevo
resultado fallido reemplaza la antigua cuarentena. Si el reintento tiene éxito
por completo, SnapRAID elimina el archivo \`.unrecoverable\` obsoleto. Una
cuarentena nunca se promueve de nuevo al nombre de archivo normal.
.PP
Dado que SnapRAID identifica los archivos en cuarentena únicamente por su
nombre de archivo, cualquier archivo preexistente que utilice casualmente el
sufijo \`.unrecoverable\` puede truncarse, sobrescribirse o reemplazarse si su
nombre base coincide con un archivo que se está reparando.
sufijo \`.unrecoverable\` puede truncarse, sobrescribirse, reemplazarse o eliminarse
si su nombre base coincide con un archivo que se está reparando.
.PP
Evite utilizar la extensión \`.unrecoverable\` para archivos normales y asegúrese
de incluir \`exclude *.unrecoverable\` en su configuración para evitar que dichos

13
doc/snapraid-es.d
View file

@ -1945,14 +1945,17 @@ Problemas conocidos (Known Issues)
Cuando `fix` no puede recuperar por completo un archivo dañado, lo pone en
cuarentena añadiendo la extensión `.unrecoverable` a su nombre.
Por el contrario, si se está recuperando un archivo que falta y ya existe
un archivo `.unrecoverable` correspondiente, SnapRAID asume que es el
resultado de una recuperación incompleta anterior y reanuda la escritura en él.
Si un `fix` posterior reintenta la recuperación, crea un nuevo archivo con el
nombre de archivo normal y conserva el antiguo archivo `.unrecoverable`
mientras la recuperación está en curso. Si el reintento falla, el nuevo
resultado fallido reemplaza la antigua cuarentena. Si el reintento tiene éxito
por completo, SnapRAID elimina el archivo `.unrecoverable` obsoleto. Una
cuarentena nunca se promueve de nuevo al nombre de archivo normal.
Dado que SnapRAID identifica los archivos en cuarentena únicamente por su
nombre de archivo, cualquier archivo preexistente que utilice casualmente el
sufijo `.unrecoverable` puede truncarse, sobrescribirse o reemplazarse si su
nombre base coincide con un archivo que se está reparando.
sufijo `.unrecoverable` puede truncarse, sobrescribirse, reemplazarse o eliminarse
si su nombre base coincide con un archivo que se está reparando.
Evite utilizar la extensión `.unrecoverable` para archivos normales y asegúrese
de incluir `exclude *.unrecoverable` en su configuración para evitar que dichos

13
doc/snapraid-es.txt
View file

@ -2088,14 +2088,17 @@ los caracteres no ASCII en las rutas de configuración y filtros.
Cuando `fix` no puede recuperar por completo un archivo dañado, lo pone en
cuarentena añadiendo la extensión `.unrecoverable` a su nombre.
Por el contrario, si se está recuperando un archivo que falta y ya existe
un archivo `.unrecoverable` correspondiente, SnapRAID asume que es el
resultado de una recuperación incompleta anterior y reanuda la escritura en él.
Si un `fix` posterior reintenta la recuperación, crea un nuevo archivo con el
nombre de archivo normal y conserva el antiguo archivo `.unrecoverable`
mientras la recuperación está en curso. Si el reintento falla, el nuevo
resultado fallido reemplaza la antigua cuarentena. Si el reintento tiene éxito
por completo, SnapRAID elimina el archivo `.unrecoverable` obsoleto. Una
cuarentena nunca se promueve de nuevo al nombre de archivo normal.
Dado que SnapRAID identifica los archivos en cuarentena únicamente por su
nombre de archivo, cualquier archivo preexistente que utilice casualmente el
sufijo `.unrecoverable` puede truncarse, sobrescribirse o reemplazarse si su
nombre base coincide con un archivo que se está reparando.
sufijo `.unrecoverable` puede truncarse, sobrescribirse, reemplazarse o eliminarse
si su nombre base coincide con un archivo que se está reparando.
Evite utilizar la extensión `.unrecoverable` para archivos normales y asegúrese
de incluir `exclude *.unrecoverable` en su configuración para evitar que dichos

15
doc/snapraid-fr.1
View file

@ -2490,15 +2490,18 @@ configuration et les filtres.
Lorsque \`fix\` ne peut pas récupérer entièrement un fichier endommagé, il le
place en quarantaine en ajoutant l\'extension \`.unrecoverable\` à son nom.
.PP
Inversement, si un fichier manquant est en cours de restauration et qu\'un
fichier \`.unrecoverable\` correspondant existe déjà, SnapRAID suppose qu\'il
s\'agit du résultat d\'une récupération incomplète antérieure et reprend
l\'écriture directement dans ce fichier.
Si une commande \`fix\` ultérieure réessaie la récupération, elle crée un
nouveau fichier sous le nom normal et conserve l\'ancien fichier
\`.unrecoverable\` pendant la récupération. Si la nouvelle tentative échoue,
le nouveau résultat infructueux remplace l\'ancienne quarantaine. Si la
nouvelle tentative réussit complètement, SnapRAID supprime le fichier
\`.unrecoverable\` obsolète. Une quarantaine n\'est jamais promue à nouveau
vers le nom de fichier normal.
.PP
Étant donné que SnapRAID identifie les fichiers en quarantaine uniquement par
leur nom de fichier, tout fichier préexistant utilisant par coïncidence le
suffixe \`.unrecoverable\` peut être tronqué, écrasé ou remplacé si son nom de
base correspond à un fichier en cours de réparation.
suffixe \`.unrecoverable\` peut être tronqué, écrasé, remplacé ou supprimé si son
nom de base correspond à un fichier en cours de réparation.
.PP
Évitez d\'utiliser l\'extension \`.unrecoverable\` pour les fichiers normaux et
assurez\-vous que la règle \`exclude *.unrecoverable\` est incluse dans votre

15
doc/snapraid-fr.d
View file

@ -1988,15 +1988,18 @@ Problèmes connus (Known Issues)
Lorsque `fix` ne peut pas récupérer entièrement un fichier endommagé, il le
place en quarantaine en ajoutant l'extension `.unrecoverable` à son nom.
Inversement, si un fichier manquant est en cours de restauration et qu'un
fichier `.unrecoverable` correspondant existe déjà, SnapRAID suppose qu'il
s'agit du résultat d'une récupération incomplète antérieure et reprend
l'écriture directement dans ce fichier.
Si une commande `fix` ultérieure réessaie la récupération, elle crée un
nouveau fichier sous le nom normal et conserve l'ancien fichier
`.unrecoverable` pendant la récupération. Si la nouvelle tentative échoue,
le nouveau résultat infructueux remplace l'ancienne quarantaine. Si la
nouvelle tentative réussit complètement, SnapRAID supprime le fichier
`.unrecoverable` obsolète. Une quarantaine n'est jamais promue à nouveau
vers le nom de fichier normal.
Étant donné que SnapRAID identifie les fichiers en quarantaine uniquement par
leur nom de fichier, tout fichier préexistant utilisant par coïncidence le
suffixe `.unrecoverable` peut être tronqué, écrasé ou remplacé si son nom de
base correspond à un fichier en cours de réparation.
suffixe `.unrecoverable` peut être tronqué, écrasé, remplacé ou supprimé si son
nom de base correspond à un fichier en cours de réparation.
Évitez d'utiliser l'extension `.unrecoverable` pour les fichiers normaux et
assurez-vous que la règle `exclude *.unrecoverable` est incluse dans votre

15
doc/snapraid-fr.txt
View file

@ -2131,15 +2131,18 @@ configuration et les filtres.
Lorsque `fix` ne peut pas récupérer entièrement un fichier endommagé, il le
place en quarantaine en ajoutant l'extension `.unrecoverable` à son nom.
Inversement, si un fichier manquant est en cours de restauration et qu'un
fichier `.unrecoverable` correspondant existe déjà, SnapRAID suppose qu'il
s'agit du résultat d'une récupération incomplète antérieure et reprend
l'écriture directement dans ce fichier.
Si une commande `fix` ultérieure réessaie la récupération, elle crée un
nouveau fichier sous le nom normal et conserve l'ancien fichier
`.unrecoverable` pendant la récupération. Si la nouvelle tentative échoue,
le nouveau résultat infructueux remplace l'ancienne quarantaine. Si la
nouvelle tentative réussit complètement, SnapRAID supprime le fichier
`.unrecoverable` obsolète. Une quarantaine n'est jamais promue à nouveau
vers le nom de fichier normal.
Étant donné que SnapRAID identifie les fichiers en quarantaine uniquement par
leur nom de fichier, tout fichier préexistant utilisant par coïncidence le
suffixe `.unrecoverable` peut être tronqué, écrasé ou remplacé si son nom de
base correspond à un fichier en cours de réparation.
suffixe `.unrecoverable` peut être tronqué, écrasé, remplacé ou supprimé si son
nom de base correspond à un fichier en cours de réparation.
Évitez d'utiliser l'extension `.unrecoverable` pour les fichiers normaux et
assurez-vous que la règle `exclude *.unrecoverable` est incluse dans votre

13
doc/snapraid-it.1
View file

@ -2466,14 +2466,17 @@ configurazione e nei filtri.
Quando \`fix\` non riesce a recuperare completamente un file danneggiato,
lo mette in quarantena aggiungendo l\'estensione \`.unrecoverable\` al suo nome.
.PP
Al contrario, se si sta ripristinando un file mancante ed esiste già un
corrispondente file \`.unrecoverable\`, SnapRAID presume che sia il risultato
di un precedente recupero incompleto e riprende a scrivervi sul posto.
Se un successivo \`fix\` tenta nuovamente il recupero, crea un nuovo file con
il nome normale e preserva il vecchio file \`.unrecoverable\` durante l\'avanzamento
del recupero. Se il nuovo tentativo fallisce, il nuovo risultato fallito
sostituisce la vecchia quarantena. Se il tentativo ha completamente successo,
SnapRAID elimina il file \`.unrecoverable\` obsoleto. Un file in quarantena non
viene mai promosso nuovamente al nome di file normale.
.PP
Poiché SnapRAID identifica i file di quarantena esclusivamente dal nome del
file, qualsiasi file preesistente che utilizzi casualmente il suffisso
\`.unrecoverable\` potrebbe essere troncato, sovrascritto o sostituito se il
suo nome di base corrisponde a un file in fase di ripristino.
\`.unrecoverable\` potrebbe essere troncato, sovrascritto, sostituito o eliminato
se il suo nome di base corrisponde a un file in fase di ripristino.
.PP
Evitare di utilizzare l\'estensione \`.unrecoverable\` per i normali file e
assicurarsi che la regola \`exclude *.unrecoverable\` sia inclusa nella

13
doc/snapraid-it.d
View file

@ -1953,14 +1953,17 @@ Problemi noti (Known Issues)
Quando `fix` non riesce a recuperare completamente un file danneggiato,
lo mette in quarantena aggiungendo l'estensione `.unrecoverable` al suo nome.
Al contrario, se si sta ripristinando un file mancante ed esiste già un
corrispondente file `.unrecoverable`, SnapRAID presume che sia il risultato
di un precedente recupero incompleto e riprende a scrivervi sul posto.
Se un successivo `fix` tenta nuovamente il recupero, crea un nuovo file con
il nome normale e preserva il vecchio file `.unrecoverable` durante l'avanzamento
del recupero. Se il nuovo tentativo fallisce, il nuovo risultato fallito
sostituisce la vecchia quarantena. Se il tentativo ha completamente successo,
SnapRAID elimina il file `.unrecoverable` obsoleto. Un file in quarantena non
viene mai promosso nuovamente al nome di file normale.
Poiché SnapRAID identifica i file di quarantena esclusivamente dal nome del
file, qualsiasi file preesistente che utilizzi casualmente il suffisso
`.unrecoverable` potrebbe essere troncato, sovrascritto o sostituito se il
suo nome di base corrisponde a un file in fase di ripristino.
`.unrecoverable` potrebbe essere troncato, sovrascritto, sostituito o eliminato
se il suo nome di base corrisponde a un file in fase di ripristino.
Evitare di utilizzare l'estensione `.unrecoverable` per i normali file e
assicurarsi che la regola `exclude *.unrecoverable` sia inclusa nella

13
doc/snapraid-it.txt
View file

@ -2096,14 +2096,17 @@ configurazione e nei filtri.
Quando `fix` non riesce a recuperare completamente un file danneggiato,
lo mette in quarantena aggiungendo l'estensione `.unrecoverable` al suo nome.
Al contrario, se si sta ripristinando un file mancante ed esiste già un
corrispondente file `.unrecoverable`, SnapRAID presume che sia il risultato
di un precedente recupero incompleto e riprende a scrivervi sul posto.
Se un successivo `fix` tenta nuovamente il recupero, crea un nuovo file con
il nome normale e preserva il vecchio file `.unrecoverable` durante l'avanzamento
del recupero. Se il nuovo tentativo fallisce, il nuovo risultato fallito
sostituisce la vecchia quarantena. Se il tentativo ha completamente successo,
SnapRAID elimina il file `.unrecoverable` obsoleto. Un file in quarantena non
viene mai promosso nuovamente al nome di file normale.
Poiché SnapRAID identifica i file di quarantena esclusivamente dal nome del
file, qualsiasi file preesistente che utilizzi casualmente il suffisso
`.unrecoverable` potrebbe essere troncato, sovrascritto o sostituito se il
suo nome di base corrisponde a un file in fase di ripristino.
`.unrecoverable` potrebbe essere troncato, sovrascritto, sostituito o eliminato
se il suo nome di base corrisponde a un file in fase di ripristino.
Evitare di utilizzare l'estensione `.unrecoverable` per i normali file e
assicurarsi che la regola `exclude *.unrecoverable` sia inclusa nella

10
doc/snapraid-ja.1
View file

@ -2216,13 +2216,15 @@ Unicodeファイル名全体で大文字・小文字の不区別を強制する
\`fix\` が破損したファイルを完全に回復できない場合、その名前に \`.unrecoverable\`
拡張子を追加して隔離します。
.PP
逆に、欠落しているファイルが修復対象であり、対応する \`.unrecoverable\` ファイル
がすでに存在する場合、SnapRAID はそれが以前の不完全な回復の結果であると想定し、
そのファイルへの直接書き込みを再開します。
後から実行された \`fix\` が回復を再試行する場合、通常のファイル名で新しいファイルを
作成し、回復の進行中は古い \`.unrecoverable\` ファイルを保持します。再試行が失敗
した場合、新しい失敗した結果が古い隔離ファイルを置き換えます。再試行が完全に
成功した場合、SnapRAID は不要になった \`.unrecoverable\` ファイルを削除します。
隔離ファイルが通常のファイル名に戻されることは決してありません。
.PP
SnapRAID はファイル名のみに基づいて隔離ファイルを識別するため、偶然 \`.unrecoverable\`
サフィックスを使用している既存のファイルは、ベース名が修復中のファイルと一致すると、
切り詰められたり、上書きされたり、置換されたりする可能性があります。
切り詰められたり、上書きされたり、置換されたり、削除されたりする可能性があります。
.PP
通常のファイルには \`.unrecoverable\` 拡張子を使用しないようにし、それらのファイルが
パリティデータセットで追跡されないように設定に \`exclude *.unrecoverable\` が含まれている

10
doc/snapraid-ja.d
View file

@ -1717,13 +1717,15 @@ Name{number}
`fix` が破損したファイルを完全に回復できない場合、その名前に `.unrecoverable`
拡張子を追加して隔離します。
逆に、欠落しているファイルが修復対象であり、対応する `.unrecoverable` ファイル
がすでに存在する場合、SnapRAID はそれが以前の不完全な回復の結果であると想定し、
そのファイルへの直接書き込みを再開します。
後から実行された `fix` が回復を再試行する場合、通常のファイル名で新しいファイルを
作成し、回復の進行中は古い `.unrecoverable` ファイルを保持します。再試行が失敗
した場合、新しい失敗した結果が古い隔離ファイルを置き換えます。再試行が完全に
成功した場合、SnapRAID は不要になった `.unrecoverable` ファイルを削除します。
隔離ファイルが通常のファイル名に戻されることは決してありません。
SnapRAID はファイル名のみに基づいて隔離ファイルを識別するため、偶然 `.unrecoverable`
サフィックスを使用している既存のファイルは、ベース名が修復中のファイルと一致すると、
切り詰められたり、上書きされたり、置換されたりする可能性があります。
切り詰められたり、上書きされたり、置換されたり、削除されたりする可能性があります。
通常のファイルには `.unrecoverable` 拡張子を使用しないようにし、それらのファイルが
パリティデータセットで追跡されないように設定に `exclude *.unrecoverable` が含まれている

10
doc/snapraid-ja.txt
View file

@ -1860,13 +1860,15 @@ Unicodeファイル名全体で大文字・小文字の不区別を強制する
`fix` が破損したファイルを完全に回復できない場合、その名前に `.unrecoverable`
拡張子を追加して隔離します。
逆に、欠落しているファイルが修復対象であり、対応する `.unrecoverable` ファイル
がすでに存在する場合、SnapRAID はそれが以前の不完全な回復の結果であると想定し、
そのファイルへの直接書き込みを再開します。
後から実行された `fix` が回復を再試行する場合、通常のファイル名で新しいファイルを
作成し、回復の進行中は古い `.unrecoverable` ファイルを保持します。再試行が失敗
した場合、新しい失敗した結果が古い隔離ファイルを置き換えます。再試行が完全に
成功した場合、SnapRAID は不要になった `.unrecoverable` ファイルを削除します。
隔離ファイルが通常のファイル名に戻されることは決してありません。
SnapRAID はファイル名のみに基づいて隔離ファイルを識別するため、偶然 `.unrecoverable`
サフィックスを使用している既存のファイルは、ベース名が修復中のファイルと一致すると、
切り詰められたり、上書きされたり、置換されたりする可能性があります。
切り詰められたり、上書きされたり、置換されたり、削除されたりする可能性があります。
通常のファイルには `.unrecoverable` 拡張子を使用しないようにし、それらのファイルが
パリティデータセットで追跡されないように設定に `exclude *.unrecoverable` が含まれている

12
doc/snapraid-ko.1
View file

@ -2261,13 +2261,15 @@ Windows 파일 시스템은 임의의 시스템 종속 폴딩 테이블을 통
\`fix\`가 손상된 파일을 완전히 복구할 수 없는 경우, 이름에 \`.unrecoverable\` 확장자를
추가하여 격리합니다.
.PP
반대로 누락된 파일을 복구하는 중이고 해당하는 \`.unrecoverable\` 파일이 이미 존재하는
경우, SnapRAID는 이를 이전의 불완전한 복구 결과로 간주하고 해당 파일에 직접 쓰기를
재개합니다.
이후 \`fix\`가 복구를 재시도하는 경우, 일반 파일 이름으로 새 파일을 생성하고 복구가
진행되는 동안 이전 \`.unrecoverable\` 파일을 유지합니다. 재시도에 실패하면 새 실패
결과가 이전 격리 파일을 대체합니다. 재시도가 완전히 성공하면 SnapRAID는 더 이상
필요 없는 \`.unrecoverable\` 파일을 삭제합니다. 격리 파일은 일반 파일 이름으로 다시
승격되지 않습니다.
.PP
SnapRAID는 오직 파일 이름으로만 격리 파일을 식별하므로, 우연히 \`.unrecoverable\` 접미사를
사용하는 기존 파일의 기본 이름이 복구 중인 파일과 일치하면 잘리거나 덮어쓰이거나 대체될
수 있습니다.
사용하는 기존 파일의 기본 이름이 복구 중인 파일과 일치하면 잘리거나, 덮어쓰이거나,
대체되거나, 삭제될 수 있습니다.
.PP
일반 파일에는 \`.unrecoverable\` 확장자를 사용하지 마시고, 해당 파일이 패리티 데이터셋에서
추적되지 않도록 구성에 \`exclude *.unrecoverable\`이 포함되어 있는지 확인하십시오.

12
doc/snapraid-ko.d
View file

@ -1762,13 +1762,15 @@ Name{number}
`fix`가 손상된 파일을 완전히 복구할 수 없는 경우, 이름에 `.unrecoverable` 확장자를
추가하여 격리합니다.
반대로 누락된 파일을 복구하는 중이고 해당하는 `.unrecoverable` 파일이 이미 존재하는
경우, SnapRAID는 이를 이전의 불완전한 복구 결과로 간주하고 해당 파일에 직접 쓰기를
재개합니다.
이후 `fix`가 복구를 재시도하는 경우, 일반 파일 이름으로 새 파일을 생성하고 복구가
진행되는 동안 이전 `.unrecoverable` 파일을 유지합니다. 재시도에 실패하면 새 실패
결과가 이전 격리 파일을 대체합니다. 재시도가 완전히 성공하면 SnapRAID는 더 이상
필요 없는 `.unrecoverable` 파일을 삭제합니다. 격리 파일은 일반 파일 이름으로 다시
승격되지 않습니다.
SnapRAID는 오직 파일 이름으로만 격리 파일을 식별하므로, 우연히 `.unrecoverable` 접미사를
사용하는 기존 파일의 기본 이름이 복구 중인 파일과 일치하면 잘리거나 덮어쓰이거나 대체될
수 있습니다.
사용하는 기존 파일의 기본 이름이 복구 중인 파일과 일치하면 잘리거나, 덮어쓰이거나,
대체되거나, 삭제될 수 있습니다.
일반 파일에는 `.unrecoverable` 확장자를 사용하지 마시고, 해당 파일이 패리티 데이터셋에서
추적되지 않도록 구성에 `exclude *.unrecoverable`이 포함되어 있는지 확인하십시오.

12
doc/snapraid-ko.txt
View file

@ -1905,13 +1905,15 @@ Windows 파일 시스템은 임의의 시스템 종속 폴딩 테이블을 통
`fix`가 손상된 파일을 완전히 복구할 수 없는 경우, 이름에 `.unrecoverable` 확장자를
추가하여 격리합니다.
반대로 누락된 파일을 복구하는 중이고 해당하는 `.unrecoverable` 파일이 이미 존재하는
경우, SnapRAID는 이를 이전의 불완전한 복구 결과로 간주하고 해당 파일에 직접 쓰기를
재개합니다.
이후 `fix`가 복구를 재시도하는 경우, 일반 파일 이름으로 새 파일을 생성하고 복구가
진행되는 동안 이전 `.unrecoverable` 파일을 유지합니다. 재시도에 실패하면 새 실패
결과가 이전 격리 파일을 대체합니다. 재시도가 완전히 성공하면 SnapRAID는 더 이상
필요 없는 `.unrecoverable` 파일을 삭제합니다. 격리 파일은 일반 파일 이름으로 다시
승격되지 않습니다.
SnapRAID는 오직 파일 이름으로만 격리 파일을 식별하므로, 우연히 `.unrecoverable` 접미사를
사용하는 기존 파일의 기본 이름이 복구 중인 파일과 일치하면 잘리거나 덮어쓰이거나 대체될
수 있습니다.
사용하는 기존 파일의 기본 이름이 복구 중인 파일과 일치하면 잘리거나, 덮어쓰이거나,
대체되거나, 삭제될 수 있습니다.
일반 파일에는 `.unrecoverable` 확장자를 사용하지 마시고, 해당 파일이 패리티 데이터셋에서
추적되지 않도록 구성에 `exclude *.unrecoverable`이 포함되어 있는지 확인하십시오.

13
doc/snapraid-pl.1
View file

@ -2353,14 +2353,17 @@ w ścieżkach konfiguracyjnych i filtrach.
Gdy \`fix\` nie może w pełni odzyskać uszkodzonego pliku, poddaje go kwarantannie,
dodając do jego nazwy rozszerzenie \`.unrecoverable\`.
.PP
I odwrotnie, jeśli brakujący plik jest naprawiany, a odpowiedni plik
\`.unrecoverable\` już istnieje, SnapRAID zakłada, że jest to wynik poprzedniego
niepełnego odzyskiwania i wznawia zapis bezpośrednio w tym pliku.
Jeśli późniejsze polecenie \`fix\` ponowi próbę odzyskania, tworzy ono nowy
plik pod normalną nazwą i zachowuje stary plik \`.unrecoverable\` podczas trwania
odzyskiwania. Jeśli ponowna próba się nie powiedzie, nowy nieudany wynik
zastępuje starą kwarantannę. Jeśli ponowna próba zakończy się całkowitym
sukcesem, SnapRAID usuwa przestarzały plik \`.unrecoverable\`. Kwarantanna nigdy
nie jest przywracana do normalnej nazwy pliku.
.PP
Ponieważ SnapRAID identyfikuje pliki kwarantanny wyłącznie na podstawie ich
nazwy, każdy wcześniej istniejący plik, który przypadkowo używa sufiksu
\`.unrecoverable\`, może zostać obcięty, nadpisany lub zastąpiony, jeśli jego
nazwa bazowa odpowiada naprawianemu plikowi.
\`.unrecoverable\`, może zostać obcięty, nadpisany, zastąpiony lub usunięty, jeśli
jego nazwa bazowa odpowiada naprawianemu plikowi.
.PP
Unikaj używania rozszerzenia \`.unrecoverable\` dla zwykłych plików i upewnij się,
że w konfiguracji uwzględniono regułę \`exclude *.unrecoverable\`, aby zapobiec

13
doc/snapraid-pl.d
View file

@ -1854,14 +1854,17 @@ Znane problemy (Known Issues)
Gdy `fix` nie może w pełni odzyskać uszkodzonego pliku, poddaje go kwarantannie,
dodając do jego nazwy rozszerzenie `.unrecoverable`.
I odwrotnie, jeśli brakujący plik jest naprawiany, a odpowiedni plik
`.unrecoverable` już istnieje, SnapRAID zakłada, że jest to wynik poprzedniego
niepełnego odzyskiwania i wznawia zapis bezpośrednio w tym pliku.
Jeśli późniejsze polecenie `fix` ponowi próbę odzyskania, tworzy ono nowy
plik pod normalną nazwą i zachowuje stary plik `.unrecoverable` podczas trwania
odzyskiwania. Jeśli ponowna próba się nie powiedzie, nowy nieudany wynik
zastępuje starą kwarantannę. Jeśli ponowna próba zakończy się całkowitym
sukcesem, SnapRAID usuwa przestarzały plik `.unrecoverable`. Kwarantanna nigdy
nie jest przywracana do normalnej nazwy pliku.
Ponieważ SnapRAID identyfikuje pliki kwarantanny wyłącznie na podstawie ich
nazwy, każdy wcześniej istniejący plik, który przypadkowo używa sufiksu
`.unrecoverable`, może zostać obcięty, nadpisany lub zastąpiony, jeśli jego
nazwa bazowa odpowiada naprawianemu plikowi.
`.unrecoverable`, może zostać obcięty, nadpisany, zastąpiony lub usunięty, jeśli
jego nazwa bazowa odpowiada naprawianemu plikowi.
Unikaj używania rozszerzenia `.unrecoverable` dla zwykłych plików i upewnij się,
że w konfiguracji uwzględniono regułę `exclude *.unrecoverable`, aby zapobiec

13
doc/snapraid-pl.txt
View file

@ -1997,14 +1997,17 @@ w ścieżkach konfiguracyjnych i filtrach.
Gdy `fix` nie może w pełni odzyskać uszkodzonego pliku, poddaje go kwarantannie,
dodając do jego nazwy rozszerzenie `.unrecoverable`.
I odwrotnie, jeśli brakujący plik jest naprawiany, a odpowiedni plik
`.unrecoverable` już istnieje, SnapRAID zakłada, że jest to wynik poprzedniego
niepełnego odzyskiwania i wznawia zapis bezpośrednio w tym pliku.
Jeśli późniejsze polecenie `fix` ponowi próbę odzyskania, tworzy ono nowy
plik pod normalną nazwą i zachowuje stary plik `.unrecoverable` podczas trwania
odzyskiwania. Jeśli ponowna próba się nie powiedzie, nowy nieudany wynik
zastępuje starą kwarantannę. Jeśli ponowna próba zakończy się całkowitym
sukcesem, SnapRAID usuwa przestarzały plik `.unrecoverable`. Kwarantanna nigdy
nie jest przywracana do normalnej nazwy pliku.
Ponieważ SnapRAID identyfikuje pliki kwarantanny wyłącznie na podstawie ich
nazwy, każdy wcześniej istniejący plik, który przypadkowo używa sufiksu
`.unrecoverable`, może zostać obcięty, nadpisany lub zastąpiony, jeśli jego
nazwa bazowa odpowiada naprawianemu plikowi.
`.unrecoverable`, może zostać obcięty, nadpisany, zastąpiony lub usunięty, jeśli
jego nazwa bazowa odpowiada naprawianemu plikowi.
Unikaj używania rozszerzenia `.unrecoverable` dla zwykłych plików i upewnij się,
że w konfiguracji uwzględniono regułę `exclude *.unrecoverable`, aby zapobiec

13
doc/snapraid-pt.1
View file

@ -2391,14 +2391,17 @@ caracteres não\-ASCII em caminhos de configuração e filtros.
Quando o \`fix\` não consegue recuperar totalmente um arquivo danificado, ele o
coloca em quarentena adicionando a extensão \`.unrecoverable\` ao seu nome.
.PP
Por outro lado, se um arquivo ausente estiver sendo restaurado e já existir
um arquivo \`.unrecoverable\` correspondente, o SnapRAID assume que é o resultado
de uma recuperação incompleta anterior e retoma a gravação diretamente nele.
Se um \`fix\` posterior tentar novamente a recuperação, ele cria um novo
arquivo com o nome normal e preserva o arquivo \`.unrecoverable\` antigo
enquanto a recuperação estiver em andamento. Se a nova tentativa falhar, o novo
resultado com falha substituirá a quarentena antiga. Se a nova tentativa for
totalmente bem\-sucedida, o SnapRAID excluirá o arquivo \`.unrecoverable\`
obsoleto. Uma quarentena nunca é promovida de volta ao nome de arquivo normal.
.PP
Como o SnapRAID identifica os arquivos de quarentena exclusivamente pelo nome
do arquivo, qualquer arquivo pré\-existente que coincidentemente use o sufixo
\`.unrecoverable\` pode ser truncado, sobrescrito ou substituído se seu nome
base coincidir com o arquivo que está sendo restaurado.
\`.unrecoverable\` pode ser truncado, sobrescrito, substituído ou excluído se seu
nome base coincidir com o arquivo que está sendo restaurado.
.PP
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

13
doc/snapraid-pt.d
View file

@ -1892,14 +1892,17 @@ Problemas Conhecidos (Known Issues)
Quando o `fix` não consegue recuperar totalmente um arquivo danificado, ele o
coloca em quarentena adicionando a extensão `.unrecoverable` ao seu nome.
Por outro lado, se um arquivo ausente estiver sendo restaurado e já existir
um arquivo `.unrecoverable` correspondente, o SnapRAID assume que é o resultado
de uma recuperação incompleta anterior e retoma a gravação diretamente nele.
Se um `fix` posterior tentar novamente a recuperação, ele cria um novo
arquivo com o nome normal e preserva o arquivo `.unrecoverable` antigo
enquanto a recuperação estiver em andamento. Se a nova tentativa falhar, o novo
resultado com falha substituirá a quarentena antiga. Se a nova tentativa for
totalmente bem-sucedida, o SnapRAID excluirá o arquivo `.unrecoverable`
obsoleto. Uma quarentena nunca é promovida de volta ao nome de arquivo normal.
Como o SnapRAID identifica os arquivos de quarentena exclusivamente pelo nome
do arquivo, qualquer arquivo pré-existente que coincidentemente use o sufixo
`.unrecoverable` pode ser truncado, sobrescrito ou substituído se seu nome
base coincidir com o arquivo que está sendo restaurado.
`.unrecoverable` pode ser truncado, sobrescrito, substituído ou excluído se seu
nome base coincidir com o arquivo que está sendo restaurado.
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

13
doc/snapraid-pt.txt
View file

@ -2035,14 +2035,17 @@ caracteres não-ASCII em caminhos de configuração e filtros.
Quando o `fix` não consegue recuperar totalmente um arquivo danificado, ele o
coloca em quarentena adicionando a extensão `.unrecoverable` ao seu nome.
Por outro lado, se um arquivo ausente estiver sendo restaurado e já existir
um arquivo `.unrecoverable` correspondente, o SnapRAID assume que é o resultado
de uma recuperação incompleta anterior e retoma a gravação diretamente nele.
Se um `fix` posterior tentar novamente a recuperação, ele cria um novo
arquivo com o nome normal e preserva o arquivo `.unrecoverable` antigo
enquanto a recuperação estiver em andamento. Se a nova tentativa falhar, o novo
resultado com falha substituirá a quarentena antiga. Se a nova tentativa for
totalmente bem-sucedida, o SnapRAID excluirá o arquivo `.unrecoverable`
obsoleto. Uma quarentena nunca é promovida de volta ao nome de arquivo normal.
Como o SnapRAID identifica os arquivos de quarentena exclusivamente pelo nome
do arquivo, qualquer arquivo pré-existente que coincidentemente use o sufixo
`.unrecoverable` pode ser truncado, sobrescrito ou substituído se seu nome
base coincidir com o arquivo que está sendo restaurado.
`.unrecoverable` pode ser truncado, sobrescrito, substituído ou excluído se seu
nome base coincidir com o arquivo que está sendo restaurado.
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

13
doc/snapraid-ro.1
View file

@ -2350,14 +2350,17 @@ caracterelor non\-ASCII în căile de configurare și filtre.
Când \`fix\` nu poate recupera complet un fișier deteriorat, îl plasează în
carantină adăugând extensia \`.unrecoverable\` la numele său.
.PP
Dimpotrivă, dacă un fișier lipsă este în curs de reparare și există deja un
fișier \`.unrecoverable\` corespunzător, SnapRAID presupune că acesta este
rezultatul unei recuperări incomplete anterioare și reia scrierea direct în el.
Dacă o comandă \`fix\` ulterioară reîncearcă recuperarea, aceasta creează un
fișier nou sub numele normal și păstrează vechiul fișier \`.unrecoverable\`
în timp ce recuperarea este în curs. Dacă reîncercarea eșuează, noul rezultat
eșuat înlocuiește vechea carantină. Dacă reîncercarea reușește complet,
SnapRAID șterge fișierul \`.unrecoverable\` învechit. O carantină nu este
niciodată promovată înapoi la numele de fișier normal.
.PP
Deoarece SnapRAID identifică fișierele de carantină exclusiv după numele lor,
orice fișier preexistent care folosește din coincidență sufixul \`.unrecoverable\`
poate fi trunchiat, suprascris sau înlocuit dacă numele său de bază corespunde
unui fișier în curs de reparare.
poate fi trunchiat, suprascris, înlocuit sau șters dacă numele său de bază
corespunde unui fișier în curs de reparare.
.PP
Evitați utilizarea extensiei \`.unrecoverable\` pentru fișiere obișnuite și
asigurați\-vă că \`exclude *.unrecoverable\` este inclus în configurație pentru

13
doc/snapraid-ro.d
View file

@ -1851,14 +1851,17 @@ Probleme Cunoscute (Known Issues)
Când `fix` nu poate recupera complet un fișier deteriorat, îl plasează în
carantină adăugând extensia `.unrecoverable` la numele său.
Dimpotrivă, dacă un fișier lipsă este în curs de reparare și există deja un
fișier `.unrecoverable` corespunzător, SnapRAID presupune că acesta este
rezultatul unei recuperări incomplete anterioare și reia scrierea direct în el.
Dacă o comandă `fix` ulterioară reîncearcă recuperarea, aceasta creează un
fișier nou sub numele normal și păstrează vechiul fișier `.unrecoverable`
în timp ce recuperarea este în curs. Dacă reîncercarea eșuează, noul rezultat
eșuat înlocuiește vechea carantină. Dacă reîncercarea reușește complet,
SnapRAID șterge fișierul `.unrecoverable` învechit. O carantină nu este
niciodată promovată înapoi la numele de fișier normal.
Deoarece SnapRAID identifică fișierele de carantină exclusiv după numele lor,
orice fișier preexistent care folosește din coincidență sufixul `.unrecoverable`
poate fi trunchiat, suprascris sau înlocuit dacă numele său de bază corespunde
unui fișier în curs de reparare.
poate fi trunchiat, suprascris, înlocuit sau șters dacă numele său de bază
corespunde unui fișier în curs de reparare.
Evitați utilizarea extensiei `.unrecoverable` pentru fișiere obișnuite și
asigurați-vă că `exclude *.unrecoverable` este inclus în configurație pentru

13
doc/snapraid-ro.txt
View file

@ -1994,14 +1994,17 @@ caracterelor non-ASCII în căile de configurare și filtre.
Când `fix` nu poate recupera complet un fișier deteriorat, îl plasează în
carantină adăugând extensia `.unrecoverable` la numele său.
Dimpotrivă, dacă un fișier lipsă este în curs de reparare și există deja un
fișier `.unrecoverable` corespunzător, SnapRAID presupune că acesta este
rezultatul unei recuperări incomplete anterioare și reia scrierea direct în el.
Dacă o comandă `fix` ulterioară reîncearcă recuperarea, aceasta creează un
fișier nou sub numele normal și păstrează vechiul fișier `.unrecoverable`
în timp ce recuperarea este în curs. Dacă reîncercarea eșuează, noul rezultat
eșuat înlocuiește vechea carantină. Dacă reîncercarea reușește complet,
SnapRAID șterge fișierul `.unrecoverable` învechit. O carantină nu este
niciodată promovată înapoi la numele de fișier normal.
Deoarece SnapRAID identifică fișierele de carantină exclusiv după numele lor,
orice fișier preexistent care folosește din coincidență sufixul `.unrecoverable`
poate fi trunchiat, suprascris sau înlocuit dacă numele său de bază corespunde
unui fișier în curs de reparare.
poate fi trunchiat, suprascris, înlocuit sau șters dacă numele său de bază
corespunde unui fișier în curs de reparare.
Evitați utilizarea extensiei `.unrecoverable` pentru fișiere obișnuite și
asigurați-vă că `exclude *.unrecoverable` este inclus în configurație pentru

13
doc/snapraid-ru.1
View file

@ -2355,14 +2355,17 @@ Windows и ее упорным стремлением к псевдонимиз
Когда \`fix\` не может полностью восстановить поврежденный файл, он помещает его
в карантин, добавляя расширение \`.unrecoverable\` к его имени.
.PP
И наоборот, если восстанавливается отсутствующий файл и соответствующий файл
\`.unrecoverable\` уже существует, SnapRAID предполагает, что это результат
предыдущего незавершенного восстановления, и возобновляет запись прямо в него.
Если последующий \`fix\` повторяет попытку восстановления, он создает новый файл
с обычным именем и сохраняет старый файл \`.unrecoverable\` на время выполнения
восстановления. Если повторная попытка завершается неудачей, новый неудачный
результат заменяет старый карантин. Если повторная попытка полностью успешна,
SnapRAID удаляет устаревший файл \`.unrecoverable\`. Карантинный файл никогда не
возвращается к обычному имени.
.PP
Поскольку SnapRAID идентифицирует файлы карантина исключительно по имени файла,
любой ранее существовавший файл, случайно использующий суффикс \`.unrecoverable\`,
может быть усечен, перезаписан или заменен, если его базовое имя совпадает с
восстанавливаемым файлом.
может быть усечен, перезаписан, заменен или удален, если его базовое имя совпадает
с восстанавливаемым файлом.
.PP
Избегайте использования расширения \`.unrecoverable\` для обычных файлов и
убедитесь, что в вашей конфигурации указано правило \`exclude *.unrecoverable\`,

13
doc/snapraid-ru.d
View file

@ -1858,14 +1858,17 @@ Name{number}
Когда `fix` не может полностью восстановить поврежденный файл, он помещает его
в карантин, добавляя расширение `.unrecoverable` к его имени.
И наоборот, если восстанавливается отсутствующий файл и соответствующий файл
`.unrecoverable` уже существует, SnapRAID предполагает, что это результат
предыдущего незавершенного восстановления, и возобновляет запись прямо в него.
Если последующий `fix` повторяет попытку восстановления, он создает новый файл
с обычным именем и сохраняет старый файл `.unrecoverable` на время выполнения
восстановления. Если повторная попытка завершается неудачей, новый неудачный
результат заменяет старый карантин. Если повторная попытка полностью успешна,
SnapRAID удаляет устаревший файл `.unrecoverable`. Карантинный файл никогда не
возвращается к обычному имени.
Поскольку SnapRAID идентифицирует файлы карантина исключительно по имени файла,
любой ранее существовавший файл, случайно использующий суффикс `.unrecoverable`,
может быть усечен, перезаписан или заменен, если его базовое имя совпадает с
восстанавливаемым файлом.
может быть усечен, перезаписан, заменен или удален, если его базовое имя совпадает
с восстанавливаемым файлом.
Избегайте использования расширения `.unrecoverable` для обычных файлов и
убедитесь, что в вашей конфигурации указано правило `exclude *.unrecoverable`,

13
doc/snapraid-ru.txt
View file

@ -2001,14 +2001,17 @@ Windows и ее упорным стремлением к псевдонимиз
Когда `fix` не может полностью восстановить поврежденный файл, он помещает его
в карантин, добавляя расширение `.unrecoverable` к его имени.
И наоборот, если восстанавливается отсутствующий файл и соответствующий файл
`.unrecoverable` уже существует, SnapRAID предполагает, что это результат
предыдущего незавершенного восстановления, и возобновляет запись прямо в него.
Если последующий `fix` повторяет попытку восстановления, он создает новый файл
с обычным именем и сохраняет старый файл `.unrecoverable` на время выполнения
восстановления. Если повторная попытка завершается неудачей, новый неудачный
результат заменяет старый карантин. Если повторная попытка полностью успешна,
SnapRAID удаляет устаревший файл `.unrecoverable`. Карантинный файл никогда не
возвращается к обычному имени.
Поскольку SnapRAID идентифицирует файлы карантина исключительно по имени файла,
любой ранее существовавший файл, случайно использующий суффикс `.unrecoverable`,
может быть усечен, перезаписан или заменен, если его базовое имя совпадает с
восстанавливаемым файлом.
может быть усечен, перезаписан, заменен или удален, если его базовое имя совпадает
с восстанавливаемым файлом.
Избегайте использования расширения `.unrecoverable` для обычных файлов и
убедитесь, что в вашей конфигурации указано правило `exclude *.unrecoverable`,

13
doc/snapraid-sv.1
View file

@ -2347,14 +2347,17 @@ skiftläget för eventuella icke\-ASCII\-tecken i konfigurationssökvägar och f
När \`fix\` inte helt kan återställa en skadad fil sätter den filen i karantän
genom att lägga till filändelsen \`.unrecoverable\` till dess namn.
.PP
Omvänt, om en saknad fil återställs och en motsvarande \`.unrecoverable\`\-fil
redan finns, antar SnapRAID att den är resultatet av en tidigare ofullständig
återställning och återupptar skrivningen direkt i den.
Om en senare \`fix\` försöker återställa filen igen skapar den en ny fil under
det normala filnamnet och bevarar den gamla \`.unrecoverable\`\-filen medan
återställningen pågår. Om det nya försöket misslyckas ersätter det nya
misslyckade resultatet den gamla karantänen. Om det nya försöket lyckas helt
raderar SnapRAID den föråldrade \`.unrecoverable\`\-filen. En karantänfil
befordras aldrig tillbaka till det normala filnamnet.
.PP
Eftersom SnapRAID identifierar karantänfiler enbart baserat på deras filnamn,
kan alla befintliga filer som av en händelse använder suffixet \`.unrecoverable\`
avhuggas, skrivas över eller ersättas om deras basnamn matchar en fil som
håller på att återställas.
avhuggas, skrivas över, ersättas eller raderas om deras basnamn matchar en fil
som håller på att återställas.
.PP
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

13
doc/snapraid-sv.d
View file

@ -1848,14 +1848,17 @@ Kända problem (Known Issues)
När `fix` inte helt kan återställa en skadad fil sätter den filen i karantän
genom att lägga till filändelsen `.unrecoverable` till dess namn.
Omvänt, om en saknad fil återställs och en motsvarande `.unrecoverable`-fil
redan finns, antar SnapRAID att den är resultatet av en tidigare ofullständig
återställning och återupptar skrivningen direkt i den.
Om en senare `fix` försöker återställa filen igen skapar den en ny fil under
det normala filnamnet och bevarar den gamla `.unrecoverable`-filen medan
återställningen pågår. Om det nya försöket misslyckas ersätter det nya
misslyckade resultatet den gamla karantänen. Om det nya försöket lyckas helt
raderar SnapRAID den föråldrade `.unrecoverable`-filen. En karantänfil
befordras aldrig tillbaka till det normala filnamnet.
Eftersom SnapRAID identifierar karantänfiler enbart baserat på deras filnamn,
kan alla befintliga filer som av en händelse använder suffixet `.unrecoverable`
avhuggas, skrivas över eller ersättas om deras basnamn matchar en fil som
håller på att återställas.
avhuggas, skrivas över, ersättas eller raderas om deras basnamn matchar en fil
som håller på att återställas.
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

13
doc/snapraid-sv.txt
View file

@ -1991,14 +1991,17 @@ skiftläget för eventuella icke-ASCII-tecken i konfigurationssökvägar och fil
När `fix` inte helt kan återställa en skadad fil sätter den filen i karantän
genom att lägga till filändelsen `.unrecoverable` till dess namn.
Omvänt, om en saknad fil återställs och en motsvarande `.unrecoverable`-fil
redan finns, antar SnapRAID att den är resultatet av en tidigare ofullständig
återställning och återupptar skrivningen direkt i den.
Om en senare `fix` försöker återställa filen igen skapar den en ny fil under
det normala filnamnet och bevarar den gamla `.unrecoverable`-filen medan
återställningen pågår. Om det nya försöket misslyckas ersätter det nya
misslyckade resultatet den gamla karantänen. Om det nya försöket lyckas helt
raderar SnapRAID den föråldrade `.unrecoverable`-filen. En karantänfil
befordras aldrig tillbaka till det normala filnamnet.
Eftersom SnapRAID identifierar karantänfiler enbart baserat på deras filnamn,
kan alla befintliga filer som av en händelse använder suffixet `.unrecoverable`
avhuggas, skrivas över eller ersättas om deras basnamn matchar en fil som
håller på att återställas.
avhuggas, skrivas över, ersättas eller raderas om deras basnamn matchar en fil
som håller på att återställas.
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

13
doc/snapraid-uk.1
View file

@ -2553,14 +2553,17 @@ SnapRAID використовує стандартне, передбачуван
Коли \`fix\` не може повністю відновити пошкоджений файл, він поміщає його в
карантин, додаючи розширення \`.unrecoverable\` до його імені.
.PP
І навпаки, якщо відновлюється відсутній файл і відповідний файл \`.unrecoverable\`
вже існує, SnapRAID припускає, що це результат попереднього незавершеного
відновлення, і відновлює запис безпосередньо в нього.
Якщо наступний \`fix\` повторює спробу відновлення, він створює новий файл зі
звичайним ім\'ям і зберігає старий файл \`.unrecoverable\` під час виконання
відновлення. Якщо повторна спроба зазнає невдачі, новий невдалий результат
замінює старий карантин. Якщо повторна спроба повністю успішна, SnapRAID
видаляє застарілий файл \`.unrecoverable\`. Файл карантину ніколи не повертається
до звичайного імені.
.PP
Оскільки SnapRAID ідентифікує файли карантину виключно за назвою файлу, будь\-який
раніше існуючий файл, який випадково використовує суфікс \`.unrecoverable\`, може
бути усічений, перезаписаний або замінений, якщо його базова назва збігається
з файлом, що відновлюється.
бути усічений, перезаписаний, замінений або видалений, якщо його базова назва
збігається з файлом, що відновлюється.
.PP
Уникайте використання розширення \`.unrecoverable\` для звичайних файлів і
переконайтеся, що правило \`exclude *.unrecoverable\` включено до вашої

13
doc/snapraid-uk.d
View file

@ -2042,14 +2042,17 @@ Name{number}
Коли `fix` не може повністю відновити пошкоджений файл, він поміщає його в
карантин, додаючи розширення `.unrecoverable` до його імені.
І навпаки, якщо відновлюється відсутній файл і відповідний файл `.unrecoverable`
вже існує, SnapRAID припускає, що це результат попереднього незавершеного
відновлення, і відновлює запис безпосередньо в нього.
Якщо наступний `fix` повторює спробу відновлення, він створює новий файл зі
звичайним ім'ям і зберігає старий файл `.unrecoverable` під час виконання
відновлення. Якщо повторна спроба зазнає невдачі, новий невдалий результат
замінює старий карантин. Якщо повторна спроба повністю успішна, SnapRAID
видаляє застарілий файл `.unrecoverable`. Файл карантину ніколи не повертається
до звичайного імені.
Оскільки SnapRAID ідентифікує файли карантину виключно за назвою файлу, будь-який
раніше існуючий файл, який випадково використовує суфікс `.unrecoverable`, може
бути усічений, перезаписаний або замінений, якщо його базова назва збігається
з файлом, що відновлюється.
бути усічений, перезаписаний, замінений або видалений, якщо його базова назва
збігається з файлом, що відновлюється.
Уникайте використання розширення `.unrecoverable` для звичайних файлів і
переконайтеся, що правило `exclude *.unrecoverable` включено до вашої

13
doc/snapraid-uk.txt
View file

@ -2185,14 +2185,17 @@ SnapRAID використовує стандартне, передбачуван
Коли `fix` не може повністю відновити пошкоджений файл, він поміщає його в
карантин, додаючи розширення `.unrecoverable` до його імені.
І навпаки, якщо відновлюється відсутній файл і відповідний файл `.unrecoverable`
вже існує, SnapRAID припускає, що це результат попереднього незавершеного
відновлення, і відновлює запис безпосередньо в нього.
Якщо наступний `fix` повторює спробу відновлення, він створює новий файл зі
звичайним ім'ям і зберігає старий файл `.unrecoverable` під час виконання
відновлення. Якщо повторна спроба зазнає невдачі, новий невдалий результат
замінює старий карантин. Якщо повторна спроба повністю успішна, SnapRAID
видаляє застарілий файл `.unrecoverable`. Файл карантину ніколи не повертається
до звичайного імені.
Оскільки SnapRAID ідентифікує файли карантину виключно за назвою файлу, будь-який
раніше існуючий файл, який випадково використовує суфікс `.unrecoverable`, може
бути усічений, перезаписаний або замінений, якщо його базова назва збігається
з файлом, що відновлюється.
бути усічений, перезаписаний, замінений або видалений, якщо його базова назва
збігається з файлом, що відновлюється.
Уникайте використання розширення `.unrecoverable` для звичайних файлів і
переконайтеся, що правило `exclude *.unrecoverable` включено до вашої

8
doc/snapraid-zh.1
View file

@ -2110,12 +2110,14 @@ Unicode 文件名之间强制实行不区分大小写。因此，Windows 掩盖
当 \`fix\` 无法完全恢复损坏的文件时，它会通过在文件名后附加 \`.unrecoverable\`
扩展名来对其进行隔离。
.PP
相反，如果在修复缺失文件的过程中已经存在对应的 \`.unrecoverable\` 文件，
SnapRAID 会假定它是先前未完成恢复的结果，并恢复原地写入该文件。
如果后续的 \`fix\` 重试恢复，它将在常规文件名下创建一个新文件，并在恢复进行
期间保留旧的 \`.unrecoverable\` 文件。如果重试失败，新的失败结果将替换旧的
隔离文件。如果重试完全成功，SnapRAID 将删除已废弃的 \`.unrecoverable\` 文件。
隔离文件绝不会被恢复为常规文件名。
.PP
由于 SnapRAID 仅根据文件名识别隔离文件，因此任何碰巧使用 \`.unrecoverable\`
后缀的预先存在的文件，如果其基本名称与正在修复的文件匹配，都可能会被截断、
覆盖或替换。
覆盖、替换或删除。
.PP
请避免对常规文件使用 \`.unrecoverable\` 扩展名，并确保在配置中包含
\`exclude *.unrecoverable\`，以防止在奇偶校验数据集中跟踪此类文件。

8
doc/snapraid-zh.d
View file

@ -1611,12 +1611,14 @@ Name{number}
当 `fix` 无法完全恢复损坏的文件时，它会通过在文件名后附加 `.unrecoverable`
扩展名来对其进行隔离。
相反，如果在修复缺失文件的过程中已经存在对应的 `.unrecoverable` 文件，
SnapRAID 会假定它是先前未完成恢复的结果，并恢复原地写入该文件。
如果后续的 `fix` 重试恢复，它将在常规文件名下创建一个新文件，并在恢复进行
期间保留旧的 `.unrecoverable` 文件。如果重试失败，新的失败结果将替换旧的
隔离文件。如果重试完全成功，SnapRAID 将删除已废弃的 `.unrecoverable` 文件。
隔离文件绝不会被恢复为常规文件名。
由于 SnapRAID 仅根据文件名识别隔离文件，因此任何碰巧使用 `.unrecoverable`
后缀的预先存在的文件，如果其基本名称与正在修复的文件匹配，都可能会被截断、
覆盖或替换。
覆盖、替换或删除。
请避免对常规文件使用 `.unrecoverable` 扩展名，并确保在配置中包含
`exclude *.unrecoverable`，以防止在奇偶校验数据集中跟踪此类文件。

8
doc/snapraid-zh.txt
View file

@ -1754,12 +1754,14 @@ Unicode 文件名之间强制实行不区分大小写。因此，Windows 掩盖
当 `fix` 无法完全恢复损坏的文件时，它会通过在文件名后附加 `.unrecoverable`
扩展名来对其进行隔离。
相反，如果在修复缺失文件的过程中已经存在对应的 `.unrecoverable` 文件，
SnapRAID 会假定它是先前未完成恢复的结果，并恢复原地写入该文件。
如果后续的 `fix` 重试恢复，它将在常规文件名下创建一个新文件，并在恢复进行
期间保留旧的 `.unrecoverable` 文件。如果重试失败，新的失败结果将替换旧的
隔离文件。如果重试完全成功，SnapRAID 将删除已废弃的 `.unrecoverable` 文件。
隔离文件绝不会被恢复为常规文件名。
由于 SnapRAID 仅根据文件名识别隔离文件，因此任何碰巧使用 `.unrecoverable`
后缀的预先存在的文件，如果其基本名称与正在修复的文件匹配，都可能会被截断、
覆盖或替换。
覆盖、替换或删除。
请避免对常规文件使用 `.unrecoverable` 扩展名，并确保在配置中包含
`exclude *.unrecoverable`，以防止在奇偶校验数据集中跟踪此类文件。

11
doc/snapraid.1
View file

@ -2355,13 +2355,16 @@ exact case for any non\-ASCII characters in configuration paths and filters.
When \`fix\` cannot fully recover a damaged file, it quarantines it by
appending the \`.unrecoverable\` extension to its name.
.PP
Conversely, if a missing file is being fixed and a corresponding
\`.unrecoverable\` file already exists, SnapRAID assumes it is the result
of a previous incomplete recovery and resumes writing to it in\-place.
If a later \`fix\` retries the recovery, it creates a new file under the
normal filename and preserves the old \`.unrecoverable\` file while recovery
is in progress. If the retry fails, the new failed result replaces the old
quarantine. If the retry succeeds completely, SnapRAID deletes the obsolete
\`.unrecoverable\` file. A quarantine is never promoted back to the normal
filename.
.PP
Because SnapRAID identifies quarantine files solely by their filename,
any pre\-existing file that coincidentally uses the \`.unrecoverable\`
suffix may be truncated, overwritten, or replaced if its base name
suffix may be truncated, overwritten, replaced, or deleted if its base name
matches a file being fixed.
.PP
Avoid using the \`.unrecoverable\` extension for regular files, and ensure

11
doc/snapraid.d
View file

@ -1856,13 +1856,16 @@ Known Issues
When `fix` cannot fully recover a damaged file, it quarantines it by
appending the `.unrecoverable` extension to its name.
Conversely, if a missing file is being fixed and a corresponding
`.unrecoverable` file already exists, SnapRAID assumes it is the result
of a previous incomplete recovery and resumes writing to it in-place.
If a later `fix` retries the recovery, it creates a new file under the
normal filename and preserves the old `.unrecoverable` file while recovery
is in progress. If the retry fails, the new failed result replaces the old
quarantine. If the retry succeeds completely, SnapRAID deletes the obsolete
`.unrecoverable` file. A quarantine is never promoted back to the normal
filename.
Because SnapRAID identifies quarantine files solely by their filename,
any pre-existing file that coincidentally uses the `.unrecoverable`
suffix may be truncated, overwritten, or replaced if its base name
suffix may be truncated, overwritten, replaced, or deleted if its base name
matches a file being fixed.
Avoid using the `.unrecoverable` extension for regular files, and ensure

11
doc/snapraid.txt
View file

@ -1999,13 +1999,16 @@ exact case for any non-ASCII characters in configuration paths and filters.
When `fix` cannot fully recover a damaged file, it quarantines it by
appending the `.unrecoverable` extension to its name.
Conversely, if a missing file is being fixed and a corresponding
`.unrecoverable` file already exists, SnapRAID assumes it is the result
of a previous incomplete recovery and resumes writing to it in-place.
If a later `fix` retries the recovery, it creates a new file under the
normal filename and preserves the old `.unrecoverable` file while recovery
is in progress. If the retry fails, the new failed result replaces the old
quarantine. If the retry succeeds completely, SnapRAID deletes the obsolete
`.unrecoverable` file. A quarantine is never promoted back to the normal
filename.
Because SnapRAID identifies quarantine files solely by their filename,
any pre-existing file that coincidentally uses the `.unrecoverable`
suffix may be truncated, overwritten, or replaced if its base name
suffix may be truncated, overwritten, replaced, or deleted if its base name
matches a file being fixed.
Avoid using the `.unrecoverable` extension for regular files, and ensure