![]() ![]() We consider this a serious filesystem bug, however we are not concerned that this will lead to data loss on ExFAT source volumes. These aberrations are harmless as far as a backup/file copying task is concerned, but could cause trouble for other applications that expect folder inode numbers to be constant. folder inode numbers change when the volume is remounted. We have seen other related aberrant behavior on these volumes, e.g. sometimes the condition is absent when running the task again at a later time, and sometimes it recurs immediately after remounting the source volume. In the handful of cases we're tracking, the issue appears to be both transient and recurrent, e.g. CCC (6.1.4+) identifies this result, reports it as an error, and suspends any deletion/archival activity on the destination when this condition is encountered to avoid errantly removing content from the destination that was copied in a previous backup task. infinite loop) condition and refuse to enumerate the content of the corrupted subfolder. fts) identify this (correctly) as an insane "directory cycle" (i.e. Some filesystem enumeration facilities (e.g. ![]() We have seen a handful of cases where a folder's inode number is identical to the inode number of its parent folder. We're tracking a new ExFAT-specific filesystem bug in macOS Ventura. Erasing the volume is the only remaining recourse. ![]() macOS has documented functionality to remove that role, but that functionality does not work (FB7208067, Sept 2019). The underlying cause of this problem is the presence of an irrevocable "Data" role applied to that volume by Apple's ASR replication utility. Solution: Erase the volume in Disk Utility and start the backup from scratch.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |