HOW SINGAPORE EDUCATION WORKS · University research data, fixity and accountable transfer
Find your next learning step
Inventory the files, generate checksums, transfer through an approved route, verify at the destination and preserve a manifest before deleting or declaring delivery complete.
Full chapter index · Practice and checking · Sources and next reading · How Singapore Education Works
A progress bar reaching 100% shows that a transfer process ended; it does not by itself prove that every intended file arrived unchanged. A defensible handoff connects an agreed file list, source checksums, destination checksums, exceptions and sign-off.
This is a general research workflow, not a replacement for university, funder, ethics, security or data-protection requirements. Use only approved storage and transfer services. Sensitive or restricted data may require encryption, access controls and institutional review beyond the integrity checks described here.
The choices at a glance
| What you notice | Likely issue | Useful next move |
|---|---|---|
| Destination folder size looks plausible | Aggregate size can hide missing or substituted files | Compare a manifest of paths, sizes and checksums |
| One checksum differs | The file changed, the algorithm differs or the wrong file was checked | Stop, identify the exact path and recompute from the source copy |
| Files verify but collaborators cannot use them | Fixity passed while permissions, formats or documentation failed | Test access, open representative files and include a README |
Full chapter index
See the structure
Work and diagnose
Repair and practise
Recall, transfer and questions
A file transfer has at least three questions. Completeness: did every intended file arrive? Fixity: are the received bytes unchanged? Usability: can authorised recipients locate, open and interpret the material? One green tick rarely answers all three.
A checksum is a computed value derived from file contents. If the same algorithm applied to the source and destination produces the same value, that is strong evidence that the bytes match. It does not prove who created the file or whether its contents are true.
NUS research data management guidance emphasises integrity, validation and retrievability. The transfer record supports those wider responsibilities but does not replace them.
| Manifest field | Why keep it | Example |
|---|---|---|
| Relative path | Preserves folder identity | raw/site-a/run-03.csv |
| Byte size | Finds obvious truncation or substitution | 184,220 bytes |
| Checksum algorithm | Makes values comparable | SHA-256 |
| Source checksum | Fixity reference before transfer | 64 hexadecimal characters |
| Destination checksum | Evidence after transfer | Matches source |
| Status and note | Records exceptions | Verified; permission test pending |
Use relative rather than private local paths when a manifest will be shared. Keep the algorithm name beside the value; a checksum without its algorithm is ambiguous.
Do not paste confidential filenames into an unapproved service. The manifest itself may reveal participant names or project structure and must follow the same handling rules.
Assumptions: a source folder contains three files: A.csv at 120 MB, B.csv at 80 MB and notes.txt at 20 KB. A SHA-256 manifest is created. After transfer, all three paths appear at the destination. A and notes match their source checksums; B has the same displayed size but a different checksum.
The folder count and approximate total size look correct. Nevertheless, B fails fixity. Possible causes include a changed byte, transformed line endings, a different file with the same size or an incorrect comparison.
Checked decision under these assumptions: do not approve the delivery. Recompute B at both locations using the same algorithm, confirm the exact paths and, if the mismatch remains, transfer B again from the retained source copy. Approve only after the destination value matches or an authorised transformation is documented.
Never delete the source merely because names and sizes appear correct.
A missing manifest row indicates an inventory problem. A missing destination path indicates an omission. A checksum mismatch indicates different bytes. A matching checksum with an unreadable file points to format, software, permission or corruption that existed before the transfer.
Also check whether the transfer tool renamed duplicate files, flattened folders, skipped hidden files or changed symbolic links. These behaviours can produce a technically completed transfer that changes project structure.
For very large collections, automate the comparison but manually inspect the report. Automation can repeat a wrong root path or exclude a whole pattern consistently.
- Freeze or version the source set so files do not change mid-transfer.
- Create the manifest and record the checksum algorithm.
- Transfer through the institution’s approved route.
- Generate destination checksums and compare every expected row.
- Resolve exceptions, test representative files and permissions, then obtain the responsible sign-off.
- Retain the source according to policy; do not improvise deletion timing.
Checksums detect change; they are not encryption and do not provide confidentiality. Use the institution’s approved protection for restricted data.
If a service automatically transforms files, preserve originals where required and document which derivative was checked.
Guided
Transfer three non-sensitive test files. Read a prepared manifest and identify one planted mismatch.
Shared
Create a manifest for a small project folder, transfer it through an approved service and exchange verification roles with a partner.
Independent
Prepare a real handoff plan, obtain required approvals, verify the full set, document exceptions and ask the recipient to confirm access before closure.
After one week, reconstruct the five verbs from memory: freeze, manifest, transfer, verify, sign off. Then inspect an old handoff and ask whether it proves completeness, fixity and usability separately.
The same logic is used globally in archives, repositories, laboratories, fieldwork teams and cross-institution collaborations. Tools differ, but the evidence chain remains understandable: what was expected, what arrived, what matched and who accepted the result.
Changed-context transfer: verify a compressed archive and then the extracted files. Explain why a matching archive checksum proves the archive arrived unchanged but does not alone document every extracted path’s meaning.
Which checksum algorithm should I use?
Use the algorithm required or supported by the institution or repository. Record it explicitly and use the same algorithm at both ends.
Does a matching checksum prove authenticity?
It shows that two checked byte sequences match under that algorithm. Authenticity and chain of custody need additional controls.
Can I email the manifest?
Only if policy permits and the manifest contains no restricted information. Use approved channels.
When may the source be deleted?
Only under the applicable retention, project and institutional rules after verified handoff and authorised sign-off.
Sources and next reading
- NUS — Research Data Management
- NUS Libraries — Research Data Management: Data Repositories
- UK Data Service — Checksum Exercise
- UK Data Service — Managing Data During the Project