diff --git a/cmdline/elem.c b/cmdline/elem.c index aecc039d..a1bfc050 100644 --- a/cmdline/elem.c +++ b/cmdline/elem.c @@ -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) { diff --git a/cmdline/elem.h b/cmdline/elem.h index c257eb05..bf65488a 100644 --- a/cmdline/elem.h +++ b/cmdline/elem.h @@ -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; } /** diff --git a/cmdline/scan.c b/cmdline/scan.c index e27f8026..a1502090 100644 --- a/cmdline/scan.c +++ b/cmdline/scan.c @@ -16,6 +16,40 @@ static const char* es(int err) return "error"; } +/** + * If the file metadata (size and timestamp) is known to be synchronized with disk. + * + * Always set on POSIX where stat()/lstat() returns coherent metadata. On Windows NTFS, + * directory enumeration may return stale size/mtime for hardlinks until synchronized + * via lstat_sync() (GetFileInformationByHandle). + */ +#define DISCOVERY_IS_SCAN_SYNCED 0x1 + +/** + * If the file is the canonical representative among hardlinks sharing the same inode. + * + * During Phase 1, when multiple paths share an inode, one is deterministically chosen + * as canonical (via discovery_canonical_better). In Phase 2, canonical files are applied + * first to create or preserve the primary snapraid_file, while non-canonical entries + * are subsequently applied as hardlink references (snapraid_link). + */ +#define DISCOVERY_IS_CANONICAL 0x2 + +/** + * Temporary metadata collected during filesystem discovery. + */ +struct snapraid_discovery { + data_off_t size; /**< Size discovered on disk. */ + int64_t mtime_sec; /**< mtime sec discovered on disk. */ + uint64_t inode; /**< Inode discovered on disk. */ + uint64_t physical; /**< Physical offset. */ + tommy_node nodelist; /**< Node for scan->file_discovery_list. */ + tommy_node nodeset; /**< Node for scan->file_discovery_inodeset. */ + int mtime_nsec; /**< mtime nsec discovered on disk. */ + unsigned flag; /**< Transient discovery flags (DISCOVERY_IS_*). */ + char sub[1]; /**< Sub path of the file. Without the disk dir. The disk is implicit. */ +}; + struct snapraid_scan { struct snapraid_state* state; /**< State used. */ struct snapraid_disk* disk; /**< Disk used. */ @@ -36,6 +70,8 @@ struct snapraid_scan { unsigned count_insert; /**< Files new. */ unsigned count_remove; /**< Files removed. */ + tommy_list file_discovery_list; /**< Discovered regular files for Apply phase. */ + tommy_hashdyn file_discovery_inodeset; /**< Inode set for hardlink collision detection during Discovery. */ tommy_list file_insert_list; /**< Files to insert. */ tommy_list link_insert_list; /**< Links to insert. */ tommy_list dir_insert_list; /**< Dirs to insert. */ @@ -46,6 +82,38 @@ struct snapraid_scan { tommy_node node; }; +static struct snapraid_discovery* discovery_alloc(const char* sub, struct stat* st) +{ + struct snapraid_discovery* disc; + size_t sub_len = strlen(sub); + + disc = malloc_nofail(sizeof(struct snapraid_discovery) + sub_len); + disc->size = st->st_size; + disc->mtime_sec = st->st_mtime; + disc->mtime_nsec = STAT_NSEC(st); + disc->inode = st->st_ino; + disc->physical = FILEPHY_UNREAD_OFFSET; + disc->flag = 0; + memcpy(disc->sub, sub, sub_len + 1); + +#if HAVE_LSTAT_SYNC + if (st->st_sync != 0) { + disc->flag |= DISCOVERY_IS_SCAN_SYNCED; + } +#else + disc->flag |= DISCOVERY_IS_SCAN_SYNCED; +#endif + + return disc; +} + +static void discovery_free(void* void_disc) +{ + struct snapraid_discovery* disc = void_disc; + + free(disc); +} + static struct snapraid_scan* scan_alloc(struct snapraid_state* state, struct snapraid_disk* disk, int is_diff) { struct snapraid_scan* scan; @@ -61,6 +129,8 @@ static struct snapraid_scan* scan_alloc(struct snapraid_state* state, struct sna scan->count_change = 0; scan->count_remove = 0; scan->count_insert = 0; + tommy_list_init(&scan->file_discovery_list); + tommy_hashdyn_init(&scan->file_discovery_inodeset); tommy_list_init(&scan->file_insert_list); tommy_list_init(&scan->link_insert_list); tommy_list_init(&scan->dir_insert_list); @@ -71,41 +141,18 @@ static struct snapraid_scan* scan_alloc(struct snapraid_state* state, struct sna scan->is_diff = is_diff; scan->need_write = 0; -#if HAVE_THREAD - thread_mutex_init(&disk->stamp_mutex); -#endif - return scan; } static void scan_free(void* void_scan) { struct snapraid_scan* scan = void_scan; -#if HAVE_THREAD - thread_mutex_destroy(&scan->disk->stamp_mutex); -#endif + tommy_hashdyn_done(&scan->file_discovery_inodeset); + tommy_list_foreach(&scan->file_discovery_list, discovery_free); tommy_list_foreach(&scan->local_filter_list, filter_free); free(scan); } -static void stamp_lock(struct snapraid_disk* disk) -{ -#if HAVE_THREAD - thread_mutex_lock(&disk->stamp_mutex); -#else - (void)disk; -#endif -} - -static void stamp_unlock(struct snapraid_disk* disk) -{ -#if HAVE_THREAD - thread_mutex_unlock(&disk->stamp_mutex); -#else - (void)disk; -#endif -} - /** * Remove the specified link from the data set. */ @@ -411,26 +458,6 @@ static void scan_file_deallocate(struct snapraid_scan* scan, struct snapraid_fil static void scan_file_delayed_allocate(struct snapraid_scan* scan, struct snapraid_file* file) { - struct snapraid_state* state = scan->state; - struct snapraid_disk* disk = scan->disk; - - /* if we sort for physical offsets we have to read them for new files */ - if (state->opt.force_order == SORT_PHYSICAL - && file->physical == FILEPHY_UNREAD_OFFSET - ) { - char path_next[PATH_MAX]; - - pathprint(path_next, sizeof(path_next), "%s%s", disk->dir, file->sub); - - if (filephy(path_next, file->size, &file->physical) != 0) { - /* LCOV_EXCL_START */ - log_tag("%s:%u:%s:%s: File physycal offset error. %s.\n", es(errno), 0, disk->name, esc_tag(file->sub), strerror(errno)); - log_fatal(errno, "Error in getting the physical offset of file '%s'. %s.\n", path_next, strerror(errno)); - exit(EXIT_FAILURE); - /* LCOV_EXCL_STOP */ - } - } - /* insert in the delayed allocation list */ tommy_list_insert_tail(&scan->file_insert_list, &file->nodelist, file); } @@ -533,112 +560,19 @@ static int file_is_full_hashed_and_stable(struct snapraid_state* state, struct s return 1; } -/** - * Refresh the file info. - * - * This is needed by Windows as the normal way to list directories may report not - * updated info. Only the GetFileInformationByHandle() func, called file-by-file, - * really ensures to return synced info. - * - * If this happens, we read also the physical offset, to avoid to read it later. - */ -static void scan_file_refresh(struct snapraid_scan* scan, const char* sub, struct stat* st, uint64_t* physical) +static int discovery_inode_compare_to_arg(const void* void_arg, const void* void_data) { -#if HAVE_LSTAT_SYNC - struct snapraid_state* state = scan->state; - struct snapraid_disk* disk = scan->disk; + const uint64_t* arg = void_arg; + const struct snapraid_discovery* disc = void_data; - /* if the st_sync is not set, ensure to get synced info */ - if (st->st_sync == 0) { - char path_next[PATH_MAX]; - struct stat synced_st; - - pathprint(path_next, sizeof(path_next), "%s%s", disk->dir, sub); - - /* if we sort for physical offsets we have to read them for new files */ - if (state->opt.force_order == SORT_PHYSICAL - && *physical == FILEPHY_UNREAD_OFFSET - ) { - /* do nothing, leave the pointer to read the physical offset */ - } else { - physical = 0; /* set the pointer to 0 to read nothing */ - } - - if (lstat_sync(path_next, &synced_st, physical) != 0) { - /* LCOV_EXCL_START */ - log_tag("%s:%u:%s:%s: Stat error. %s.\n", es(errno), 0, disk->name, esc_tag(path_next), strerror(errno)); - log_fatal(errno, "Error in stat file '%s'. %s.\n", path_next, strerror(errno)); - exit(EXIT_FAILURE); - /* LCOV_EXCL_STOP */ - } - - if (st->st_mtime != synced_st.st_mtime - || st->st_mtimensec != synced_st.st_mtimensec - ) { -#ifndef _WIN32 - /* - * In Windows having different metadata is expected with open files - * because the metadata in the directory is updated only when the file - * is closed. - * - * The same happens for hardlinks that duplicate metadata. - * The link metadata is updated only when the link is opened. - * This extends also to st_size and st_nlink. - * - * See also: - * Why is the file size reported incorrectly for files that are still being written to? - * http://blogs.msdn.com/b/oldnewthing/archive/2011/12/26/10251026.aspx - */ - log_tag("%s:%u:%s:%s: Uncached time change error.\n", es(ESOFT), 0, disk->name, esc_tag(sub)); - log_error(ESOFT, "WARNING! Detected uncached time change from %" PRIu64 ".%09u to %" PRIu64 ".%09u for file '%s'\n", - (uint64_t)st->st_mtime, (uint32_t)st->st_mtimensec, (uint64_t)synced_st.st_mtime, (uint32_t)synced_st.st_mtimensec, sub); - log_error(ESOFT, "It's better if you run SnapRAID without other processes running.\n"); -#endif - st->st_mtime = synced_st.st_mtime; - st->st_mtimensec = synced_st.st_mtimensec; - } - - if (st->st_size != synced_st.st_size) { -#ifndef _WIN32 - log_tag("%s:%u:%s:%s: Uncached size change error.\n", es(ESOFT), 0, disk->name, esc_tag(sub)); - log_error(ESOFT, "WARNING! Detected uncached size change from %" PRIu64 " to %" PRIu64 " for file '%s'\n", - (uint64_t)st->st_size, (uint64_t)synced_st.st_size, sub); - log_error(ESOFT, "It's better if you run SnapRAID without other processes running.\n"); -#endif - st->st_size = synced_st.st_size; - } - - if (st->st_nlink != synced_st.st_nlink) { -#ifndef _WIN32 - log_tag("%s:%u:%s:%s: Uncached nlink change error.\n", es(ESOFT), 0, disk->name, esc_tag(sub)); - log_error(ESOFT, "WARNING! Detected uncached nlink change from %u to %u for file '%s'\n", - (uint32_t)st->st_nlink, (uint32_t)synced_st.st_nlink, sub); - log_error(ESOFT, "It's better if you run SnapRAID without other processes running.\n"); -#endif - st->st_nlink = synced_st.st_nlink; - } - - if (st->st_ino != INODE_INVALID && synced_st.st_ino != INODE_INVALID && st->st_ino != synced_st.st_ino) { - log_tag("%s:%u:%s:%s: Uncached inode change error.\n", es(ESOFT), 0, disk->name, esc_tag(sub)); - log_fatal(ESOFT, "DANGER! Detected uncached inode change from %" PRIu64 " to %" PRIu64 " for file '%s'\n", - (uint64_t)st->st_ino, (uint64_t)synced_st.st_ino, sub); - log_fatal(ESOFT, "It's better if you run SnapRAID without other processes running.\n"); - /* - * At this point, it's too late to change inode - * and having inconsistent inodes may result to internal failures - * so, it's better to abort - */ - exit(EXIT_FAILURE); - } - } -#else - (void)scan; - (void)sub; - (void)st; - (void)physical; -#endif + if (*arg < disc->inode) + return -1; + if (*arg > disc->inode) + return 1; + return 0; } + /** * Insert the file in the inode set. */ @@ -657,10 +591,8 @@ static void scan_file_stamp_insert(struct snapraid_scan* scan, struct snapraid_f { struct snapraid_disk* disk = scan->disk; - stamp_lock(disk); tommy_hashdyn_insert(&disk->pathset, &file->pathset, file, file_path_hash(file->sub)); tommy_hashdyn_insert(&disk->stampset, &file->stampset, file, file_stamp_hash(file->size, file->mtime_sec, file->mtime_nsec)); - stamp_unlock(disk); } /** @@ -676,10 +608,8 @@ static void scan_file_remove(struct snapraid_scan* scan, struct snapraid_file* f if (file->inode != INODE_INVALID) tommy_hashdyn_remove_existing(&disk->inodeset, &file->nodeset); - stamp_lock(disk); tommy_hashdyn_remove_existing(&disk->pathset, &file->pathset); tommy_hashdyn_remove_existing(&disk->stampset, &file->stampset); - stamp_unlock(disk); /* * Keep track of the removed file (that won't be added later) @@ -699,8 +629,8 @@ static void scan_file_remove(struct snapraid_scan* scan, struct snapraid_file* f * Deallocate the file from the parity. * * This is safe to run unlocked because: - * 1. Modified files deallocations are deferred to Phase 2 (mono-threaded phase). - * 2. Invalid parity files deallocated in Phase 1 are never selected by + * 1. Modified files deallocations are deferred to Phase 3 (mono-threaded phase). + * 2. Invalid parity files deallocated in Phase 2 are never selected by * file_is_full_hashed_and_stable() during copy-detection (since they lack * valid parity blocks). */ @@ -718,7 +648,7 @@ static void scan_file_remove(struct snapraid_scan* scan, struct snapraid_file* f * This could happen after a failed sync, when some other files are deleted, * and then new ones can be moved backward to fill the hole created. */ -static void scan_file_keep(struct snapraid_scan* scan, struct snapraid_file* file) +static void scan_file_keep(struct snapraid_scan* scan, struct snapraid_file* file, struct snapraid_discovery* disc) { struct snapraid_disk* disk = scan->disk; @@ -728,21 +658,44 @@ static void scan_file_keep(struct snapraid_scan* scan, struct snapraid_file* fil struct snapraid_file* copy = file_dup(file); file_flag_set(copy, FILE_IS_REALLOC_NEW); + /* update physical offset if provided by discovery */ + if (disc->physical != FILEPHY_UNREAD_OFFSET) + copy->physical = disc->physical; + /* insert in the delayed allocation list */ scan_file_delayed_allocate(scan, copy); - /* mark the file to be removed on Phase 2 */ + /* mark the file to be removed on Phase 3 */ file_flag_set(file, FILE_IS_REALLOC_OLD); } } /** - * Process a file. + * Process and classify a discovered file in Phase 2. + * + * Invariants maintained during application: + * - Equal, moved, or restored files are marked FILE_IS_PRESENT and keep their allocations. + * - For every valid inode encountered, disk->inodeset points to the current + * FILE_IS_PRESENT file. Later paths with the same inode are represented as hardlinks. + * - Files with INODE_INVALID are never inserted into inodeset. Inode validity + * does not change when their path/stamp insertion is scheduled. + * - A new normal file is immediately inserted into all applicable + * inode/path/stamp sets and queued for delayed parity allocation in Phase 4. + * - For a modified file, FILE_IS_MODIFIED_OLD has INODE_INVALID and is no + * longer in inodeset, but remains in pathset/stampset and filelist. + * FILE_IS_MODIFIED_NEW is in inodeset only if its inode is valid, has no + * path/stamp entry, and is queued for Phase 4. + * - For a reallocated unchanged file, FILE_IS_REALLOC_OLD remains in all its + * original containers. FILE_IS_REALLOC_NEW is only queued for Phase 4 and + * is not inserted into any file container yet. */ -static void scan_file(struct snapraid_scan* scan, int is_diff, const char* sub, struct stat* st, uint64_t physical) +static void scan_file_apply(void* void_scan, void* void_disc) { + struct snapraid_scan* scan = void_scan; + struct snapraid_discovery* disc = void_disc; struct snapraid_state* state = scan->state; struct snapraid_disk* disk = scan->disk; + int is_diff = scan->is_diff; struct snapraid_file* file; tommy_node* i; int is_original_file_size_different_than_zero; @@ -752,6 +705,11 @@ static void scan_file(struct snapraid_scan* scan, int is_diff, const char* sub, int file_already_present_mtime_nsec; int is_file_reported; int is_file_modified; + const char* sub = disc->sub; + uint64_t inode = disc->inode; + data_off_t size = disc->size; + int64_t mtime_sec = disc->mtime_sec; + int mtime_nsec = disc->mtime_nsec; /* * If the disk has persistent inodes and UUID, try a search on the past inodes, * to detect moved files. @@ -784,7 +742,6 @@ static void scan_file(struct snapraid_scan* scan, int is_diff, const char* sub, * Always search with the new inode, in the all new inodes found until now, * with the eventual presence of also the past inodes */ - uint64_t inode = st->st_ino; /* don't know the exact type of st_ino and we cannot pass it by pointer in the search */ if (inode != INODE_INVALID) file = tommy_hashdyn_search(&disk->inodeset, file_inode_compare_to_arg, &inode, file_inode_hash(inode)); else @@ -793,20 +750,12 @@ static void scan_file(struct snapraid_scan* scan, int is_diff, const char* sub, /* identify moved files with past inodes and hardlinks with the new inodes */ if (file) { /* check if the file is not changed */ - if (file->size == st->st_size - && file->mtime_sec == st->st_mtime - && file->mtime_nsec == STAT_NSEC(st) + if (file->size == size + && file->mtime_sec == mtime_sec + && file->mtime_nsec == mtime_nsec ) { /* check if multiple files have the same inode */ if (file_flag_has(file, FILE_IS_PRESENT)) { - /* if has_volatile_hardlinks is true, the nlink value is not reliable */ - if (!disk->has_volatile_hardlinks && st->st_nlink == 1) { - /* LCOV_EXCL_START */ - log_fatal(EINTERNAL, "Internal inode '%" PRIu64 "' inconsistency for file '%s%s' already present\n", (uint64_t)st->st_ino, disk->dir, sub); - os_abort(); - /* LCOV_EXCL_STOP */ - } - /* it's a hardlink */ scan_link(scan, is_diff, sub, file->sub, FILE_IS_HARDLINK); return; @@ -815,6 +764,9 @@ static void scan_file(struct snapraid_scan* scan, int is_diff, const char* sub, /* mark as present */ file_flag_set(file, FILE_IS_PRESENT); + /* this old file was physically found during Discovery, possibly under a new pathname */ + file_flag_set(file, FILE_IS_DISCOVERED); + if (strcmp(file->sub, sub) != 0) { /* if the path is different, it means a moved file with the same inode */ ++scan->count_move; @@ -827,15 +779,8 @@ static void scan_file(struct snapraid_scan* scan, int is_diff, const char* sub, /* remove from the name set */ tommy_hashdyn_remove_existing(&disk->pathset, &file->pathset); - /* - * Protect the file->sub mutation because other threads may concurrently - * search the stampset and read this file's name string inside - * file_namestamp_compare/file_pathstamp_compare, or when doing - * a pathcpy() during copy detection. - */ - stamp_lock(disk); + /* rename the file (safe without locks in serialized apply) */ file_rename(file, sub); - stamp_unlock(disk); /* reinsert in the name set */ tommy_hashdyn_insert(&disk->pathset, &file->pathset, file, file_path_hash(file->sub)); @@ -852,7 +797,7 @@ static void scan_file(struct snapraid_scan* scan, int is_diff, const char* sub, } /* mark the file as kept */ - scan_file_keep(scan, file); + scan_file_keep(scan, file, disc); /* nothing more to do */ return; @@ -878,18 +823,6 @@ static void scan_file(struct snapraid_scan* scan, int is_diff, const char* sub, * ...both time and size of A and B don't match! */ if (file_flag_has(file, FILE_IS_PRESENT)) { - /* if has_volatile_hardlinks is true, the nlink value is not reliable */ - if (!disk->has_volatile_hardlinks && st->st_nlink == 1) { - /* LCOV_EXCL_START */ - log_fatal(EINTERNAL, "Internal inode '%" PRIu64 "' inconsistency for files '%s%s' and '%s%s' with same inode but different attributes: size %" PRIu64 "?%" PRIu64 ", sec %" PRIu64 "?%" PRIu64 ", nsec %d?%d\n", - file->inode, disk->dir, sub, disk->dir, file->sub, - file->size, (uint64_t)st->st_size, - file->mtime_sec, (uint64_t)st->st_mtime, - file->mtime_nsec, STAT_NSEC(st)); - os_abort(); - /* LCOV_EXCL_STOP */ - } - /* LCOV_EXCL_START */ /* suppose it's hardlink with not synced metadata */ scan_link(scan, is_diff, sub, file->sub, FILE_IS_HARDLINK); @@ -936,14 +869,14 @@ static void scan_file(struct snapraid_scan* scan, int is_diff, const char* sub, /* if the file is without an inode */ if (file->inode == INODE_INVALID) { /* set it now */ - file->inode = st->st_ino; + file->inode = inode; /* insert in the set if valid */ if (file->inode != INODE_INVALID) tommy_hashdyn_insert(&disk->inodeset, &file->nodeset, file, file_inode_hash(file->inode)); } else { /* here the inode has to be different, otherwise we would have found it before */ - if (file->inode == st->st_ino) { + if (file->inode == inode) { /* LCOV_EXCL_START */ log_fatal(EINTERNAL, "Internal inconsistency in inode '%" PRIu64 "' for file '%s%s' as unexpected matching\n", file->inode, disk->dir, sub); os_abort(); @@ -960,15 +893,15 @@ static void scan_file(struct snapraid_scan* scan, int is_diff, const char* sub, } /* check if the file is not changed */ - if (file->size == st->st_size - && file->mtime_sec == st->st_mtime - && file->mtime_nsec == STAT_NSEC(st) + if (file->size == size + && file->mtime_sec == mtime_sec + && file->mtime_nsec == mtime_nsec ) { /* mark as present */ file_flag_set(file, FILE_IS_PRESENT); /* if when processing the disk we used the past inodes values */ - if (has_past_inodes && file->inode != INODE_INVALID && st->st_ino != INODE_INVALID) { + if (has_past_inodes && file->inode != INODE_INVALID && inode != INODE_INVALID) { /* * If persistent inodes are supported, we are sure that the inode number * is now different, because otherwise the file would have been found @@ -987,7 +920,7 @@ static void scan_file(struct snapraid_scan* scan, int is_diff, const char* sub, tommy_hashdyn_remove_existing(&disk->inodeset, &file->nodeset); /* save the new inode */ - file->inode = st->st_ino; + file->inode = inode; /* reinsert in the inode set */ tommy_hashdyn_insert(&disk->inodeset, &file->nodeset, file, file_inode_hash(file->inode)); @@ -1008,7 +941,7 @@ static void scan_file(struct snapraid_scan* scan, int is_diff, const char* sub, } /* mark the file as kept */ - scan_file_keep(scan, file); + scan_file_keep(scan, file, disc); /* nothing more to do */ return; @@ -1030,10 +963,10 @@ static void scan_file(struct snapraid_scan* scan, int is_diff, const char* sub, file->inode = INODE_INVALID; } - /* mark it as to be removed in Phase 2 */ + /* mark it as to be removed in Phase 3 */ file_flag_set(file, FILE_IS_MODIFIED_OLD); - /* flag the modified version to defer path/stamp insertion to Phase 3 */ + /* flag the modified version to defer path/stamp insertion to Phase 4 */ is_file_modified = 1; /* and continue to insert it again */ @@ -1043,20 +976,13 @@ static void scan_file(struct snapraid_scan* scan, int is_diff, const char* sub, file_already_present_mtime_nsec = 0; } - /* - * Refresh the info, to ensure that they are synced, - * note that we refresh only the info of the new or modified files - * because this is slow operation - */ - scan_file_refresh(scan, sub, st, &physical); - #ifndef _WIN32 /* * Do a safety check to ensure that the common ext4 case of zeroing * the size of a file after a crash doesn't propagate to the backup * this check is specific for Linux, so we disable it on Windows */ - if (is_original_file_size_different_than_zero && st->st_size == 0) { + if (is_original_file_size_different_than_zero && disc->size == 0) { if (!state->opt.force_zero) { /* LCOV_EXCL_START */ log_error(ESOFT, "The file '%s%s' has unexpected zero size!\n", disk->mount_point, sub); @@ -1075,10 +1001,11 @@ static void scan_file(struct snapraid_scan* scan, int is_diff, const char* sub, #endif /* insert it */ - file = file_alloc(state->block_size, sub, st->st_size, st->st_mtime, STAT_NSEC(st), st->st_ino, physical); + file = file_alloc(state->block_size, sub, disc->size, disc->mtime_sec, disc->mtime_nsec, disc->inode, disc->physical); - /* mark it as present */ + /* mark it as present and physically discovered during Phase 1 */ file_flag_set(file, FILE_IS_PRESENT); + file_flag_set(file, FILE_IS_DISCOVERED); /* * If copy detection is enabled @@ -1095,9 +1022,6 @@ static void scan_file(struct snapraid_scan* scan, int is_diff, const char* sub, struct snapraid_disk* other_disk = i->data; struct snapraid_file* other_file; - char sub_other[PATH_MAX]; - - stamp_lock(other_disk); /* * If the nanosecond part of the time stamp is valid, search * for name and stamp, otherwise for path and stamp @@ -1107,46 +1031,34 @@ static void scan_file(struct snapraid_scan* scan, int is_diff, const char* sub, else other_file = tommy_hashdyn_search(&other_disk->stampset, file_pathstamp_compare, file, hash); - if (other_file) { - /* copy sub path safely before unlocking stamp_lock */ - pathcpy(sub_other, sizeof(sub_other), other_file->sub); - } - stamp_unlock(other_disk); - /* * If found, check stability and copy the hash. * - * This is safe to execute unlocked because: - * 1. Modified files deallocations are deferred to Phase 2 (mono-threaded phase). + * This is safe to execute without locks because: + * 1. Modified files deallocations are deferred to Phase 3. * 2. file_is_full_reallocatable_and_stable() only accepts files with complete * reallocatable parity, preventing them from being selected by file_is_full_hashed_and_stable(). */ if (other_file && file_is_full_hashed_and_stable(scan->state, other_disk, other_file)) { - char path_other[PATH_MAX]; - struct stat other_st; - - stamp_lock(other_disk); file_flag_set(other_file, FILE_IS_RELOCATED); - stamp_unlock(other_disk); /* assume that the file is a copy, and reuse the hash */ file_copy(other_file, file); /* check if other file still exists */ - pathprint(path_other, sizeof(path_other), "%s%s", other_disk->dir, sub_other); - if (lstat(path_other, &other_st) == 0) { + if (file_flag_has(other_file, FILE_IS_DISCOVERED)) { ++scan->count_copy; - log_tag("scan:copy:%s:%s:%s:%s\n", other_disk->name, esc_tag(sub_other), disk->name, esc_tag(file->sub)); + log_tag("scan:copy:%s:%s:%s:%s\n", other_disk->name, esc_tag(other_file->sub), disk->name, esc_tag(file->sub)); if (is_diff) { - msg_info("copy %s -> %s\n", fmt_term(other_disk, sub_other), fmt_term(disk, file->sub)); + msg_info("copy %s -> %s\n", fmt_term(other_disk, other_file->sub), fmt_term(disk, file->sub)); } } else { ++scan->count_relocate; - log_tag("scan:relocate:%s:%s:%s:%s\n", other_disk->name, esc_tag(sub_other), disk->name, esc_tag(file->sub)); + log_tag("scan:relocate:%s:%s:%s:%s\n", other_disk->name, esc_tag(other_file->sub), disk->name, esc_tag(file->sub)); if (is_diff) { - msg_info("relocate %s -> %s\n", fmt_term(other_disk, sub_other), fmt_term(disk, file->sub)); + msg_info("relocate %s -> %s\n", fmt_term(other_disk, other_file->sub), fmt_term(disk, file->sub)); } } @@ -1190,9 +1102,9 @@ static void scan_file(struct snapraid_scan* scan, int is_diff, const char* sub, scan_file_stamp_insert(scan, file); } else { /* - * Insert the new inode before scanning the next path, so paths with the + * Insert the new inode before applying the next file, so paths with the * same inode are recognized as hardlinks to this file. Keep the old - * path/stamp entries until Phase 2; the new entries are inserted in Phase 3. + * path/stamp entries until Phase 3; the new entries are inserted in Phase 4. */ scan_file_inode_insert(scan, file); file_flag_set(file, FILE_IS_MODIFIED_NEW); @@ -1202,6 +1114,146 @@ static void scan_file(struct snapraid_scan* scan, int is_diff, const char* sub, scan_file_delayed_allocate(scan, file); } +/** + * Check if candidate discovery is better suited as canonical representative than current. + * + * Preserves existing canonical files on persistent-inode filesystems, + * falling back to deterministic pathcmp() ordering. + */ +static int discovery_canonical_better(struct snapraid_scan* scan, struct snapraid_discovery* candidate, struct snapraid_discovery* current) +{ + struct snapraid_disk* disk = scan->disk; + + /* on filesystems where previous inodes are reliable, preserve the previous canonical file if still present */ + if (!disk->has_volatile_inodes && !disk->has_different_uuid && !disk->has_unsupported_uuid) { + uint64_t inode = candidate->inode; + struct snapraid_file* old_file = tommy_hashdyn_search(&disk->inodeset, file_inode_compare_to_arg, &inode, file_inode_hash(inode)); + if (old_file) { + if (pathcmp(candidate->sub, old_file->sub) == 0) + return 1; + if (pathcmp(current->sub, old_file->sub) == 0) + return 0; + } + } + + /* deterministic fallback: minimum pathcmp() ordering */ + return pathcmp(candidate->sub, current->sub) < 0; +} + +static void scan_file_discover(struct snapraid_scan* scan, const char* sub, struct stat* st) +{ + struct snapraid_disk* disk = scan->disk; + struct snapraid_discovery* disc; + + disc = discovery_alloc(sub, st); + + /* Hardlink collision detection */ + if (disc->inode != INODE_INVALID) { + struct snapraid_discovery* rep = tommy_hashdyn_search(&scan->file_discovery_inodeset, discovery_inode_compare_to_arg, &disc->inode, file_inode_hash(disc->inode)); + if (!rep) { + /* first file seen with this inode: becomes representative */ + disc->flag |= DISCOVERY_IS_CANONICAL; + tommy_hashdyn_insert(&scan->file_discovery_inodeset, &disc->nodeset, disc, file_inode_hash(disc->inode)); + } else { + /* Inode collision detected! */ +#if HAVE_LSTAT_SYNC + if (disk->has_volatile_hardlinks && !(rep->flag & DISCOVERY_IS_SCAN_SYNCED)) { + char path_next[PATH_MAX]; + struct stat synced_st; + + pathprint(path_next, sizeof(path_next), "%s%s", disk->dir, sub); + if (lstat_sync(path_next, &synced_st, 0) != 0) { + /* LCOV_EXCL_START */ + log_tag("%s:%u:%s:%s: Stat error. %s.\n", es(errno), 0, disk->name, esc_tag(path_next), strerror(errno)); + log_fatal(errno, "Error in stat file '%s'. %s.\n", path_next, strerror(errno)); + exit(EXIT_FAILURE); + /* LCOV_EXCL_STOP */ + } + + if (disc->inode != INODE_INVALID && synced_st.st_ino != INODE_INVALID && disc->inode != synced_st.st_ino) { + log_tag("%s:%u:%s:%s: Uncached inode change error.\n", es(ESOFT), 0, disk->name, esc_tag(sub)); + log_fatal(ESOFT, "DANGER! Detected uncached inode change from %" PRIu64 " to %" PRIu64 " for file '%s'\n", + (uint64_t)disc->inode, (uint64_t)synced_st.st_ino, sub); + log_fatal(ESOFT, "It's better if you run SnapRAID without other processes running.\n"); + exit(EXIT_FAILURE); + } + + rep->size = synced_st.st_size; + rep->mtime_sec = synced_st.st_mtime; + rep->mtime_nsec = STAT_NSEC(&synced_st); + rep->flag |= DISCOVERY_IS_SCAN_SYNCED; + + disc->size = rep->size; + disc->mtime_sec = rep->mtime_sec; + disc->mtime_nsec = rep->mtime_nsec; + disc->flag |= DISCOVERY_IS_SCAN_SYNCED; + } else +#endif + if (rep->flag & DISCOVERY_IS_SCAN_SYNCED) { + disc->size = rep->size; + disc->mtime_sec = rep->mtime_sec; + disc->mtime_nsec = rep->mtime_nsec; + disc->flag |= DISCOVERY_IS_SCAN_SYNCED; + } + + /* select deterministic canonical representative */ + if (discovery_canonical_better(scan, disc, rep)) { + rep->flag &= ~DISCOVERY_IS_CANONICAL; + disc->flag |= DISCOVERY_IS_CANONICAL; + tommy_hashdyn_remove_existing(&scan->file_discovery_inodeset, &rep->nodeset); + tommy_hashdyn_insert(&scan->file_discovery_inodeset, &disc->nodeset, disc, file_inode_hash(disc->inode)); + } + } + } + + /* + * If this file corresponds to an existing file moved under a new pathname, + * match it by inode and normalized metadata on filesystems with persistent inodes. + * Marking it FILE_IS_DISCOVERED in Phase 1 ensures all moved files across all + * disks are flagged before Phase 2 copy detection runs, avoiding any dependency + * on disk processing order in scanlist. + */ + if (!disk->has_volatile_inodes && !disk->has_different_uuid && !disk->has_unsupported_uuid && disc->inode != INODE_INVALID) { + struct snapraid_file* inode_file; + uint64_t inode = disc->inode; + + inode_file = tommy_hashdyn_search(&disk->inodeset, file_inode_compare_to_arg, &inode, file_inode_hash(inode)); + if (inode_file + && inode_file->size == disc->size + && inode_file->mtime_sec == disc->mtime_sec + && inode_file->mtime_nsec == disc->mtime_nsec + ) { + file_flag_set(inode_file, FILE_IS_DISCOVERED); + } + } + + tommy_list_insert_tail(&scan->file_discovery_list, &disc->nodelist, disc); +} + +static void scan_file_apply_canonical(void* void_scan, void* void_disc) +{ + struct snapraid_discovery* disc = void_disc; + + if (disc->inode == INODE_INVALID || (disc->flag & DISCOVERY_IS_CANONICAL) != 0) + scan_file_apply(void_scan, void_disc); +} + +static void scan_file_apply_hardlink(void* void_scan, void* void_disc) +{ + struct snapraid_discovery* disc = void_disc; + + if (disc->inode != INODE_INVALID && (disc->flag & DISCOVERY_IS_CANONICAL) == 0) + scan_file_apply(void_scan, void_disc); +} + +static void scan_apply(struct snapraid_scan* scan) +{ + tommy_list_foreach_arg(&scan->file_discovery_list, scan_file_apply_canonical, scan); + tommy_list_foreach_arg(&scan->file_discovery_list, scan_file_apply_hardlink, scan); + tommy_list_foreach(&scan->file_discovery_list, discovery_free); + tommy_list_init(&scan->file_discovery_list); +} + /** * Remove the specified dir from the data set. */ @@ -1571,17 +1623,17 @@ static int scan_sub(struct snapraid_scan* scan, int level, int is_diff, char* pa || (filter_path(&state->filterlist, &reason, disk->name, sub_next) == 0 && filter_path(&scan->local_filter_list, &reason, disk->name, sub_next) == 0)) { + struct snapraid_file* existing; + /* late stat, if not yet called */ if (!st) st = DSTAT(path_next, dd, &st_buf); #if HAVE_LSTAT_SYNC /* - * In Windows fast directory enumeration, st_ino and st_nlink may be - * missing (0). If a field is needed, lstat_sync() must be called to - * retrieve it. Here only st_ino is required for file identity and - * hardlink tracking, while st_nlink is not; we call lstat_sync() only - * when st_ino is missing to avoid expensive file opens. + * In Windows fast directory enumeration, st_ino may be missing (0). + * Only st_ino is required for file identity and hardlink tracking; + * we call lstat_sync() only when st_ino is missing to avoid expensive file opens. */ if (st->st_ino == INODE_INVALID) { if (lstat_sync(path_next, st, 0) != 0) { @@ -1594,7 +1646,11 @@ static int scan_sub(struct snapraid_scan* scan, int level, int is_diff, char* pa } #endif - scan_file(scan, is_diff, sub_next, st, FILEPHY_UNREAD_OFFSET); + existing = tommy_hashdyn_search(&disk->pathset, file_path_compare_to_arg, sub_next, file_path_hash(sub_next)); + if (existing) + file_flag_set(existing, FILE_IS_DISCOVERED); + + scan_file_discover(scan, sub_next, st); processed = 1; } else { msg_verbose("Excluding file '%s' for rule '%s'\n", path_next, filter_type(reason, tmp, PATH_MAX)); @@ -1728,9 +1784,66 @@ static int scan_dir(struct snapraid_scan* scan, int level, int is_diff, const ch return scan_sub(scan, level, is_diff, path_next, sub_next, tmp); } +/** + * Resolve physical offset for a single discovered regular file entry. + * + * Hardlink aliases are skipped because they are never allocated in parity and do not + * participate in physical ordering. + */ +static void scan_discovery_physical_entry(void* void_scan, void* void_disc) +{ + struct snapraid_scan* scan = void_scan; + struct snapraid_state* state = scan->state; + struct snapraid_disk* disk = scan->disk; + struct snapraid_discovery* disc = void_disc; + struct snapraid_file* existing; + char path_next[PATH_MAX]; + + /* skip hardlink aliases; only canonical representatives or standalone files need physical offsets */ + if (disc->inode != INODE_INVALID && (disc->flag & DISCOVERY_IS_CANONICAL) == 0) + return; + + /* search existing file by path, or by inode if moved or promoted */ + existing = tommy_hashdyn_search(&disk->pathset, file_path_compare_to_arg, disc->sub, file_path_hash(disc->sub)); + if (!existing) { + if (!disk->has_volatile_inodes && !disk->has_different_uuid && !disk->has_unsupported_uuid && disc->inode != INODE_INVALID) + existing = tommy_hashdyn_search(&disk->inodeset, file_inode_compare_to_arg, &disc->inode, file_inode_hash(disc->inode)); + } + + /* reuse physical offset if the file exists unchanged and is not being reallocated */ + if (existing + && existing->size == disc->size + && existing->mtime_sec == disc->mtime_sec + && existing->mtime_nsec == disc->mtime_nsec + && !file_is_full_reallocatable_and_stable(state, disk, existing) + ) { + disc->physical = existing->physical; + return; + } + + pathprint(path_next, sizeof(path_next), "%s%s", disk->dir, disc->sub); + + if (filephy(path_next, disc->size, &disc->physical) != 0) { + /* LCOV_EXCL_START */ + log_tag("%s:%u:%s:%s: File physycal offset error. %s.\n", es(errno), 0, disk->name, esc_tag(disc->sub), strerror(errno)); + log_fatal(errno, "Error in getting the physical offset of file '%s'. %s.\n", path_next, strerror(errno)); + exit(EXIT_FAILURE); + /* LCOV_EXCL_STOP */ + } +} + +/** + * Resolve physical offsets for canonical files and standalone regular files in Phase 1B. + */ +static void scan_discovery_physical(struct snapraid_scan* scan) +{ + tommy_list_foreach_arg(&scan->file_discovery_list, scan_discovery_physical_entry, scan); +} + static void* scan_disk(void* arg) { struct snapraid_scan* scan = arg; + struct snapraid_state* state = scan->state; struct snapraid_disk* disk = scan->disk; int ret; int has_persistent_inodes; @@ -1759,7 +1872,7 @@ static void* scan_disk(void* arg) * Remove all the inodes from the inode collection * if they are not persistent, all of them could be changed now * and we don't want to find false matching ones - * See scan_file() for more details + * See scan_file_apply() for more details */ tommy_node* node = disk->filelist; while (node) { @@ -1797,6 +1910,9 @@ static void* scan_disk(void* arg) scan_dir(scan, 0, scan->is_diff, disk->dir, ""); + if (state->opt.force_order == SORT_PHYSICAL) + scan_discovery_physical(scan); + if (!scan->is_diff) msg_progress("Scanned %s in %" PRIu64 " seconds\n", disk->name, (os_tick_ms() - start) / 1000); @@ -1832,38 +1948,26 @@ static int state_diffscan(struct snapraid_state* state, int is_diff) } /* - * We split the search in three phases: - * Phase 1: Parallel scanning of directories, finding new and modified files (without deletions/deallocations). - * Phase 2: Serialized removals (deleted files and old versions of modified files) to free up parity space. - * Phase 3: Serialized insertions and allocations of new files. + * We split the search in four phases: + * Phase 1: Parallel directory Discovery, collecting metadata and normalizing volatile hardlinks. + * Phase 2: Serialized Apply, classifying discovered files, updating counters/logs, and detecting copies. + * Phase 3: Serialized removals (deleted files and old versions of modified files) to free up parity space. + * Phase 4: Serialized insertions and allocations of new files. * - * We must start Phase 2 (deletions) only when all disks have finished Phase 1 (scanning), + * We must start Phase 3 (deletions) only when all disks have finished Phase 2 (Apply), * to ensure that copy/relocation detection on any disk can search the stampset of other disks * before their old files are deleted/deallocated. */ /* - * Phase 1: Parallel scanning of directories + * Phase 1: Parallel directory Discovery * * Invariants during and after this phase: - * - Each disk is modified only by its scan thread. Cross-disk stampset - * accesses used by copy/relocate detection are protected by stamp_lock(). - * - No old file, link, directory, or parity allocation is removed. This keeps - * every old stamp available to all scan threads for copy/relocate detection. - * - For every valid inode already encountered in the current scan, inodeset - * points to the current FILE_IS_PRESENT file. Later paths with the same inode - * are therefore represented as hardlinks to that single file. - * - Files with INODE_INVALID are never inserted into inodeset. Inode validity - * does not change when their path/stamp insertion is scheduled. - * - A new normal file is immediately inserted into all applicable - * inode/path/stamp sets and queued for delayed parity allocation. - * - For a modified file, FILE_IS_MODIFIED_OLD has INODE_INVALID and is no - * longer in inodeset, but remains in pathset/stampset and filelist. - * FILE_IS_MODIFIED_NEW is in inodeset only if its inode is valid, has no - * path/stamp entry, and is queued for Phase 3. - * - For a reallocated unchanged file, FILE_IS_REALLOC_OLD remains in all its - * original containers. FILE_IS_REALLOC_NEW is only queued for Phase 3 and - * is not inserted into any file container yet. + * - Each disk is read only by its scan thread, enumerating files and populating + * file_discovery_list without observable SnapRAID classification side effects. + * - No old file, link, directory, or parity allocation is removed. + * - Inode collisions on volatile-hardlink filesystems trigger selective lstat_sync() + * to normalize authoritative metadata across hardlink groups before Apply. */ for (i = scanlist; i != 0; i = i->next) { struct snapraid_scan* scan = i->data; @@ -1889,6 +1993,42 @@ static int state_diffscan(struct snapraid_state* state, int is_diff) } #endif + msg_progress("Applying...\n"); + + /* + * Phase 2: Serialized Apply of discovered regular files + * + * Invariants during and after this phase: + * - All Phase 1 Discovery threads have terminated, so file enumeration, + * authoritative metadata synchronization, and filesystem I/O are complete across all disks. + * - Apply performs purely in-memory operations with zero filesystem calls. + * - Each disk's discovered files are classified against past state (equal, + * move, restore, update, add, hardlink) and state mutations (counters, + * log tags, FILE_IS_PRESENT, copy detection) occur here. + * - Serialized execution ensures copy/relocate detection against stampsets + * of other disks is completely deterministic and free of race conditions. + * - No old file, link, directory, or parity allocation is removed. This keeps + * every old stamp available to all disks for copy/relocate detection. + * - For every valid inode already encountered in the current scan, inodeset + * points to the current FILE_IS_PRESENT file. Later paths with the same inode + * are therefore represented as hardlinks to that single file. + * - Files with INODE_INVALID are never inserted into inodeset. Inode validity + * does not change when their path/stamp insertion is scheduled. + * - A new normal file is immediately inserted into all applicable + * inode/path/stamp sets and queued for delayed parity allocation in Phase 4. + * - For a modified file, FILE_IS_MODIFIED_OLD has INODE_INVALID and is no + * longer in inodeset, but remains in pathset/stampset and filelist. + * FILE_IS_MODIFIED_NEW is in inodeset only if its inode is valid, has no + * path/stamp entry, and is queued for Phase 4. + * - For a reallocated unchanged file, FILE_IS_REALLOC_OLD remains in all its + * original containers. FILE_IS_REALLOC_NEW is only queued for Phase 4 and + * is not inserted into any file container yet. + */ + for (i = scanlist; i != 0; i = i->next) { + struct snapraid_scan* scan = i->data; + scan_apply(scan); + } + for (i = scanlist; i != 0; i = i->next) { struct snapraid_scan* scan = i->data; struct snapraid_disk* disk = scan->disk; @@ -1898,10 +2038,10 @@ static int state_diffscan(struct snapraid_state* state, int is_diff) struct snapraid_file* phy_file_last; /* - * Phase 2: Removals (deleted files and old versions of modified files) + * Phase 3: Removals (deleted files and old versions of modified files) * * Invariants on entry and during this phase: - * - All Phase 1 scan threads have terminated, so removals are serialized and + * - All Phase 1 and Phase 2 operations have terminated, so removals are serialized and * no copy/relocate detection can still reference an old stamp or allocation. * - Existing files not marked FILE_IS_PRESENT are still in their applicable * inode/path/stamp sets and filelist, ready for normal removal. @@ -1915,7 +2055,7 @@ static int state_diffscan(struct snapraid_state* state, int is_diff) * versions are also in file_insert_list, without parity allocation or * filelist membership. * - Every old file/link/directory node is removed at most once. Deallocation - * happens before any Phase 3 allocation, making the freed parity reusable. + * happens before any Phase 4 allocation, making the freed parity reusable. * - On exit, no old path/stamp entry conflicts with a queued modified version; * a queued reallocation has no old inode/path/stamp entry left either. */ @@ -1933,7 +2073,7 @@ static int state_diffscan(struct snapraid_state* state, int is_diff) } else if (file_flag_has(file, FILE_IS_MODIFIED_OLD)) { scan_file_remove(scan, file, 1); } else if (!file_flag_has(file, FILE_IS_PRESENT)) { - /* here we are in mono-thread context, no need to use the stamp_lock() to read FILE_IS_RELOCATED */ + /* check if the file was relocated to another disk */ if (!file_flag_has(file, FILE_IS_RELOCATED)) { ++scan->count_remove; @@ -1983,7 +2123,7 @@ static int state_diffscan(struct snapraid_state* state, int is_diff) } /* - * Phase 3: Insertions (new files and new versions of modified files) + * Phase 4: Insertions (new files and new versions of modified files) * * Invariants on entry and after each insertion: * - All removals and deallocations for this disk are complete, and every file @@ -1991,10 +2131,10 @@ static int state_diffscan(struct snapraid_state* state, int is_diff) * - A new normal file is already in all applicable inode/path/stamp sets, so * it requires no further container insertion. * - A FILE_IS_MODIFIED_NEW with a valid inode is already in inodeset from - * Phase 1 for hardlink detection; only its path/stamp nodes are inserted here. + * Phase 2 for hardlink detection; only its path/stamp nodes are inserted here. * - FILE_IS_REALLOC_NEW is in no file container; all its applicable * inode/path/stamp nodes are inserted here after FILE_IS_REALLOC_OLD was - * removed in Phase 2. + * removed in Phase 3. * - The flags select the insertion path directly. No lookup or idempotent * insertion is used, and every TommyDS node is inserted exactly once. * - Container insertion precedes scan_file_allocate(), which adds the parity @@ -2059,8 +2199,8 @@ static int state_diffscan(struct snapraid_state* state, int is_diff) /* insert the delayed containers before allocating the file */ if (file_flag_has(file, FILE_IS_MODIFIED_NEW)) { /* - * The inode was already inserted in Phase 1, so later paths with the same - * inode could be recognized as hardlinks. Now that Phase 2 removed the old + * The inode was already inserted in Phase 2, so later paths with the same + * inode could be recognized as hardlinks. Now that Phase 3 removed the old * version, insert only the new path/stamp entries. */ scan_file_stamp_insert(scan, file); diff --git a/doc/snapraid-de.1 b/doc/snapraid-de.1 index 829a6b9f..956484b8 100644 --- a/doc/snapraid-de.1 +++ b/doc/snapraid-de.1 @@ -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. diff --git a/doc/snapraid-de.d b/doc/snapraid-de.d index 7abb53db..6db5c79b 100644 --- a/doc/snapraid-de.d +++ b/doc/snapraid-de.d @@ -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. diff --git a/doc/snapraid-de.txt b/doc/snapraid-de.txt index de260118..0fe86e7c 100644 --- a/doc/snapraid-de.txt +++ b/doc/snapraid-de.txt @@ -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) ============================ diff --git a/doc/snapraid-es.1 b/doc/snapraid-es.1 index a1f72dc4..b861d252 100644 --- a/doc/snapraid-es.1 +++ b/doc/snapraid-es.1 @@ -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. diff --git a/doc/snapraid-es.d b/doc/snapraid-es.d index d3f16374..0de0be90 100644 --- a/doc/snapraid-es.d +++ b/doc/snapraid-es.d @@ -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. diff --git a/doc/snapraid-es.txt b/doc/snapraid-es.txt index dd04322b..9e65917c 100644 --- a/doc/snapraid-es.txt +++ b/doc/snapraid-es.txt @@ -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) =========================== diff --git a/doc/snapraid-fr.1 b/doc/snapraid-fr.1 index 9f988151..281d4634 100644 --- a/doc/snapraid-fr.1 +++ b/doc/snapraid-fr.1 @@ -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. diff --git a/doc/snapraid-fr.d b/doc/snapraid-fr.d index bd57df89..12761193 100644 --- a/doc/snapraid-fr.d +++ b/doc/snapraid-fr.d @@ -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. diff --git a/doc/snapraid-fr.txt b/doc/snapraid-fr.txt index 03485bf8..49e70312 100644 --- a/doc/snapraid-fr.txt +++ b/doc/snapraid-fr.txt @@ -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) =========================== diff --git a/doc/snapraid-it.1 b/doc/snapraid-it.1 index f6d81663..1a6ec0d5 100644 --- a/doc/snapraid-it.1 +++ b/doc/snapraid-it.1 @@ -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. diff --git a/doc/snapraid-it.d b/doc/snapraid-it.d index 1ef8ae21..1cdec69d 100644 --- a/doc/snapraid-it.d +++ b/doc/snapraid-it.d @@ -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. diff --git a/doc/snapraid-it.txt b/doc/snapraid-it.txt index 8366933c..5aad5d4a 100644 --- a/doc/snapraid-it.txt +++ b/doc/snapraid-it.txt @@ -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) =========================== diff --git a/doc/snapraid-ja.1 b/doc/snapraid-ja.1 index 8d21ef3f..0f05ddd6 100644 --- a/doc/snapraid-ja.1 +++ b/doc/snapraid-ja.1 @@ -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) この文書は英語版マニュアルの自動翻訳です。 正確な記述については英語版マニュアルを参照してください。 diff --git a/doc/snapraid-ja.d b/doc/snapraid-ja.d index 0ee715e0..36088049 100644 --- a/doc/snapraid-ja.d +++ b/doc/snapraid-ja.d @@ -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) この文書は英語版マニュアルの自動翻訳です。 正確な記述については英語版マニュアルを参照してください。 diff --git a/doc/snapraid-ja.txt b/doc/snapraid-ja.txt index c380515e..281b4bfd 100644 --- a/doc/snapraid-ja.txt +++ b/doc/snapraid-ja.txt @@ -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) =================== diff --git a/doc/snapraid-ko.1 b/doc/snapraid-ko.1 index 8780ed91..ab3ab803 100644 --- a/doc/snapraid-ko.1 +++ b/doc/snapraid-ko.1 @@ -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) 이 문서는 영어 매뉴얼의 자동 번역본입니다. 공식 버전은 영어 매뉴얼을 참조하십시오. diff --git a/doc/snapraid-ko.d b/doc/snapraid-ko.d index 591f5fcb..48c99fac 100644 --- a/doc/snapraid-ko.d +++ b/doc/snapraid-ko.d @@ -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) 이 문서는 영어 매뉴얼의 자동 번역본입니다. 공식 버전은 영어 매뉴얼을 참조하십시오. diff --git a/doc/snapraid-ko.txt b/doc/snapraid-ko.txt index 6ad6bac3..22e86668 100644 --- a/doc/snapraid-ko.txt +++ b/doc/snapraid-ko.txt @@ -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) =================== diff --git a/doc/snapraid-pl.1 b/doc/snapraid-pl.1 index 3408915d..e71c1c40 100644 --- a/doc/snapraid-pl.1 +++ b/doc/snapraid-pl.1 @@ -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. diff --git a/doc/snapraid-pl.d b/doc/snapraid-pl.d index 9935646c..1d50a32d 100644 --- a/doc/snapraid-pl.d +++ b/doc/snapraid-pl.d @@ -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. diff --git a/doc/snapraid-pl.txt b/doc/snapraid-pl.txt index 19b0c7b9..095e078d 100644 --- a/doc/snapraid-pl.txt +++ b/doc/snapraid-pl.txt @@ -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) ============================ diff --git a/doc/snapraid-pt.1 b/doc/snapraid-pt.1 index 91ad2eff..5d979e39 100644 --- a/doc/snapraid-pt.1 +++ b/doc/snapraid-pt.1 @@ -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. diff --git a/doc/snapraid-pt.d b/doc/snapraid-pt.d index 52213fc3..32ed8b03 100644 --- a/doc/snapraid-pt.d +++ b/doc/snapraid-pt.d @@ -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. diff --git a/doc/snapraid-pt.txt b/doc/snapraid-pt.txt index 34fd6f47..0ce2cffd 100644 --- a/doc/snapraid-pt.txt +++ b/doc/snapraid-pt.txt @@ -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) ========================= diff --git a/doc/snapraid-ro.1 b/doc/snapraid-ro.1 index 0eb3d292..529bb245 100644 --- a/doc/snapraid-ro.1 +++ b/doc/snapraid-ro.1 @@ -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ă. diff --git a/doc/snapraid-ro.d b/doc/snapraid-ro.d index 49bc835a..a97392fe 100644 --- a/doc/snapraid-ro.d +++ b/doc/snapraid-ro.d @@ -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ă. diff --git a/doc/snapraid-ro.txt b/doc/snapraid-ro.txt index 3cb92d40..0ab491f3 100644 --- a/doc/snapraid-ro.txt +++ b/doc/snapraid-ro.txt @@ -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) ========================== diff --git a/doc/snapraid-ru.1 b/doc/snapraid-ru.1 index 90261603..9b401838 100644 --- a/doc/snapraid-ru.1 +++ b/doc/snapraid-ru.1 @@ -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) Этот документ является автоматическим переводом английского руководства. Обратитесь к английскому руководству за официальной версией. diff --git a/doc/snapraid-ru.d b/doc/snapraid-ru.d index d720634d..9f344c06 100644 --- a/doc/snapraid-ru.d +++ b/doc/snapraid-ru.d @@ -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) Этот документ является автоматическим переводом английского руководства. Обратитесь к английскому руководству за официальной версией. diff --git a/doc/snapraid-ru.txt b/doc/snapraid-ru.txt index c7d51b6e..763bea40 100644 --- a/doc/snapraid-ru.txt +++ b/doc/snapraid-ru.txt @@ -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) ======================== diff --git a/doc/snapraid-sv.1 b/doc/snapraid-sv.1 index 4c8e7f69..456a012b 100644 --- a/doc/snapraid-sv.1 +++ b/doc/snapraid-sv.1 @@ -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. diff --git a/doc/snapraid-sv.d b/doc/snapraid-sv.d index c0d8442b..30aa2e64 100644 --- a/doc/snapraid-sv.d +++ b/doc/snapraid-sv.d @@ -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. diff --git a/doc/snapraid-sv.txt b/doc/snapraid-sv.txt index bd182eb4..50656649 100644 --- a/doc/snapraid-sv.txt +++ b/doc/snapraid-sv.txt @@ -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) ============================= diff --git a/doc/snapraid-uk.1 b/doc/snapraid-uk.1 index 4f162bd2..6ac05bc7 100644 --- a/doc/snapraid-uk.1 +++ b/doc/snapraid-uk.1 @@ -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) Цей документ є автоматичним перекладом англійського посібника. Зверніться до англійського посібника для отримання офіційної версії. diff --git a/doc/snapraid-uk.d b/doc/snapraid-uk.d index bd66440f..2234f856 100644 --- a/doc/snapraid-uk.d +++ b/doc/snapraid-uk.d @@ -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) Цей документ є автоматичним перекладом англійського посібника. Зверніться до англійського посібника для отримання офіційної версії. diff --git a/doc/snapraid-uk.txt b/doc/snapraid-uk.txt index 5931b412..89aded1e 100644 --- a/doc/snapraid-uk.txt +++ b/doc/snapraid-uk.txt @@ -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) ========================= diff --git a/doc/snapraid-zh.1 b/doc/snapraid-zh.1 index 01933039..3740ff24 100644 --- a/doc/snapraid-zh.1 +++ b/doc/snapraid-zh.1 @@ -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) 本文档是英文手册的自动翻译。 请参阅英文手册以获取权威版本。 diff --git a/doc/snapraid-zh.d b/doc/snapraid-zh.d index 228fcff4..ea61f795 100644 --- a/doc/snapraid-zh.d +++ b/doc/snapraid-zh.d @@ -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) 本文档是英文手册的自动翻译。 请参阅英文手册以获取权威版本。 diff --git a/doc/snapraid-zh.txt b/doc/snapraid-zh.txt index 8ec3719e..7565da86 100644 --- a/doc/snapraid-zh.txt +++ b/doc/snapraid-zh.txt @@ -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) =================== diff --git a/doc/snapraid.1 b/doc/snapraid.1 index f7bfb1c3..0a3c7c5d 100644 --- a/doc/snapraid.1 +++ b/doc/snapraid.1 @@ -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 diff --git a/doc/snapraid.d b/doc/snapraid.d index 8912af71..6230ea9e 100644 --- a/doc/snapraid.d +++ b/doc/snapraid.d @@ -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 diff --git a/doc/snapraid.txt b/doc/snapraid.txt index 8acc4653..6c9c45d1 100644 --- a/doc/snapraid.txt +++ b/doc/snapraid.txt @@ -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 ============