Function librapidarchive::traverse::traverse

pub fn traverse<'a, 'b, P: AsRef<Path>, Q, F>(
    path: P, 
    archive_header_fn: &'a F, 
    c: SyncSender<Q>, 
    relative_path: Option<P>
) -> Result<()> where
    P: Send + Sync + Clone,
    Q: Send + Sized + 'a,
    F: Fn(&Path, &Path, &Metadata, &SyncSender<Q>) -> Result<()> + Send + Sync + 'a,
    'a: 'b, 

Traverse a directory and stream it and it's contents into memory.

Traversal occurs in a multi-threaded manner to maximize I/O queue utilization. The given archive_header_fn will be called within said tasks with the absolute and relative file names, and non-symlink metadata, to do with as it wishes.

Relative path management in the age of maximum path lengths

Due to a certain really weird OS that breaks my tape drives with a security update and ignores path restrictions on a specific type of absolute path, traverse will automatically canonicalize all paths into that form while traversing directories. Because it is impossible to even canonicalize such paths once they exceed PATH_MAX on Windows, traverse always reports absolute paths for I/O as well as a relative path for archivers.

I believe, though I haven't tested this just yet, that fs::canonicalize also strips symlink paths out, so if you plan to preserve symlinks then it's important to not store canonicalized paths in your archives.

Multithreaded communication

For convenience we also allow the caller to provide a SyncSender which will be cloned and distributed throughout the job queue.