Linux rsync lab

Before you begin

Use an instructor-prepared Ubuntu/Debian Linux machine or VM with Bash, rsync, and Python 3.9 or later. Other Linux distributions can use the same scripts after a local pilot. Python uses only its standard library; no pip packages are required. The scripts require Linux and do not run under Windows PowerShell or Git Bash.

Extract the kit into a persistent class folder on a local Linux filesystem, such as your home directory. Open a terminal in the extracted folder containing Student. Keep that session open. Run scripts as your ordinary account using bash; no sudo or chmod step is needed. Avoid temporary folders, network shares, cloud-synced folders, and Windows-mounted paths for this lab.

Use the HTML guide's Copy code buttons. Run one block at a time, read its result, and stop on an error. Quotes preserve spaces in paths. A backslash at a line's end continues a Bash command; do not put a space after it.

Practice boundary and testing status

Use synthetic files only. The kit supplies four .sh entrypoints and a shared Python helper. The comparison reads both trees without writing files; a separate saving step writes under Records. No student script deletes source or destination files. Reading a live system can still have side effects; this kit does not provide write protection or a snapshot.

This edition passed all 12 tests in Ubuntu 26.04.1 under WSL1 on September 20, 2026, including real Bash/rsync execution. Before class, the instructor must repeat the self-test in the actual classroom environment. NISTIR 8387 supports the preservation principles; it does not certify this classroom software or guarantee admissibility (Guttman et al., 2022, pp. 1, 6).

Repeat the synthetic copy

bash ./Student/copy-rsync-lab.sh "$lab"

Expected repeat: exit 0 and zero regular files transferred, with a new set of logs. Keep the preview and both copy records. Do not assume that the total number of files in rsync's summary equals the number of ordinary files: directory entries may be counted too.

Different exit-code rule: rsync uses 0 for success. Do not carry Robocopy's successful nonzero-code convention into this lab. Codes 23 and 24 describe partial-transfer conditions and require review here (Rsync(1) manpage, n.d.).

Student checkpoint: point to the first and repeat transfer counts. Explain why an unchanged repeat still needs a separate SHA-256 check. Do not repeat a real evidence copy merely to overwrite or hide a discrepancy.

Preserve more than a checksum

• Identify the original source, how it was created or transferred, and each custodian. A pathname alone is not provenance (Guttman et al., 2022, p. 7).
• Distinguish a protected acquired master from a verified working copy. This lab uses writable synthetic folders; it does not make either folder immutable.
• Use approved storage with individual accounts, access controls, and logging. Keep a backup at a separate location and verify transfers; two folders on one disk are not a resilient backup (Guttman et al., 2022, pp. 7–9).
• Retain native files and the software needed to read them. Follow the relevant retention and release policy (Guttman et al., 2022, pp. 9–10).

Use the same worksheet and questions

Student_Worksheet.md keeps the Windows lab's evidence-handling fields: authority and scope, source identity, method, operator, versions, times, receipts, exceptions, custody, finding, and retention. Linux-specific fields identify the distribution, filesystem, Bash, Python, and rsync versions. Use the same five defensibility questions on the next page.

Record clock source or uncertainty, not merely a UTC value. Script timestamps and account identifiers are context, not authenticated proof. Write notes as you work. Preserve earlier entries when adding dated corrections; do not reconstruct an undocumented event as if it had been recorded at the time. These fields are the teaching implementation, not a NIST-prescribed form.

Hand in the same kind of evidence packet

• Completed Student_Worksheet.md, including both separately held receipt references.
• Source, Destination, Logs, and Records from the generated lab, plus the kit scripts.
• Saved verification JSON, CSV, baseline, scripts, logs, and record manifest. Screenshots may illustrate them but cannot replace the underlying records.
• The empty-folder check and an explanation of every exception, warning, or incomplete step.

Submit through the approved class channel and retain your lab until released. The reviewer checks the baseline and record manifest against the original instructor-held receipts, then rehashes every listed record. A matching manifest supports integrity relative to that receipt; it cannot prove an unobserved collection actually occurred as described.

Write a bounded finding

“Between [UTC start] and [UTC end], I compared [count] source and [count] destination files. [count] matched by relative path, size, and SHA-256. I found [count] missing, [count] extra, and [count] different files. The source [matched/differed from] the baseline associated with receipt [reference]. Rsync reported exit [code]. EmptyFolder [result]. This check did not establish source authenticity, metadata equality, or acquisition completeness. Exceptions: [details].”

Defend your process using your records

1. What were you authorized to copy, from where, and why this method?
2. Show the baseline receipt. Who held it, and could you alter it?
3. Show the exact command, versions, logs, and full hashes supporting your finding. Why does a skipped file still need hashing?
4. What could change without this test detecting it? Explain the scope of a file-stream check and the absence of a snapshot.
5. Who handled or accessed the material? Explain every discrepancy and custody gap without claiming certainty the records do not support.

Compare the two operating systems

Explain why a first Robocopy copy can return 1 while a successful rsync copy returns 0. Identify where each kit retains its baseline, command record, and verification manifest. Discuss Linux case-sensitive names and the source trailing slash without changing the preservation standard.

For an instructor-led extension, use a separate synthetic pair with a changed, missing, and extra file. Then change both copies identically after a recorded baseline. Matching copies alone cannot show whether they changed before comparison (Guttman et al., 2022, p. 11).

This exercise supports a traceable account of your work. It does not guarantee admissibility; real cases require appropriate authority, procedures, qualifications, and review.

Important scope choices

Archive mode is not complete preservation. The familiar -a option does not include hard links, ACLs, or extended attributes by itself. Those require additional choices, support, and permissions. This introductory kit uses explicit ordinary-file options and does not verify metadata (Rsync(1) manpage, n.d.).

Copying can overwrite. Destination-only files remain because the helper does not use deletion options. Selected destination files can still be replaced during a copy. The repeat exercise is only for the generated synthetic lab.

Reject unsupported objects. Links, hard-linked files, special files, and detected filesystem boundaries stop the helper. A real collection requires a documented handling plan; silently omitting an object is not a complete acquisition.

Keep the source stable. The helper checks file identity, size, and times around reads and checks for common changes during enumeration. These checks do not create a snapshot or prove that a live source was unchanged throughout the operation. Case-sensitive names are paired exactly. Windows/Linux metadata and path rules are not interchangeable.

Common problems

Missing command or wrong platform: stop and ask the instructor to prepare Linux, Bash, rsync, and Python 3.9+. The instructor self-test is required before class. Do not bypass the Linux guard to claim a Windows run qualifies the kit.

Permission denied or special file: retain the message and clarify scope. Do not use sudo, change evidence permissions, or remove an item merely to force a PASS.

Invalid receipt or JSON: use the original receipt and the current result variable. If comparison failed, it produced no completed JSON. Do not paste an old PASS result into the saving step.

Source and implementation boundaries

APA 7 citations identify the source of a claim. NIST locators use the printed report pages, not PDF viewer positions. NISTIR 8387 supports preservation principles; the rsync manual describes transfer behavior, and Python documentation describes the hashing library. The scripts, receipts, worksheet, and lesson sequence are this kit's implementation.

The instructor package includes a NIST crosswalk, answer key, Linux self-test, and testing-status record. The Windows and Linux kits assess the same evidence-handling reasoning. Neither provides a complete imaging, write-protection, custody, or legal-admissibility system.

Instructor pilot before teaching

Run bash ./Instructor/test-lab.sh "$PWD" as an ordinary Linux user. It creates separate synthetic test fixtures and retains its results. A clean run must have no failures, errors, or skips, and NativeLinuxQualified must be true. Record the distribution, filesystem, Bash/Python/rsync versions, UTC time, and test-result location. Investigate any discrepancy before deploying the lesson to students.

The current draft passed all 12 tests on Ubuntu 26.04.1/WSL1 with wslfs (rw,noatime), Bash 5.3.9, Python 3.14.4 and rsync 3.4.1. No failures, errors or skips occurred. Retain that result and repeat qualification on the classroom VM/filesystem.