dosfstools

Overview

dosfstools provides command-line utilities for working with FAT file systems. Upstream describes the project as a set of tools for creating, checking, and labeling FAT-family file systems. For a Linux distribution, this package is useful wherever FAT volumes need to be created or maintained from the command line, especially during installation, recovery, removable-media handling, or imaging workflows. (github.com)

Purpose and typical use cases

Typical uses include:

• creating a FAT file system on a block device or image
• checking and repairing a FAT file system
• assigning or changing a FAT volume label
• supporting scripts and tooling that prepare removable media or disk images

Typical users include:

• administrators who work with boot media, removable storage, or rescue workflows
• developers who generate FAT images for tests, installers, or embedded systems
• CI/CD maintainers who need deterministic file-system preparation in build or test jobs
• desktop users who occasionally need to inspect or repair FAT-formatted media

Upstream project

The upstream project is dosfstools, hosted on GitHub. Upstream reports the main utilities as mkfs.fat, fsck.fat, and fatlabel, and the project is distributed under GPL-3.0-or-later. Upstream also notes that the build uses Autotools and that some generated build files are not stored in the VCS checkout; NiceOS maintainers should verify any packaging workflow that regenerates build-system files. (github.com)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic
• SOURCES/ — source manifests and other source-related metadata used by the packaging workflow
• METADATA/ — repository metadata used by the NiceOS packaging infrastructure
• SBOM/ — software bill of materials artifacts, when present for this package

Large upstream source archives are intentionally not stored in this Git repository. Instead, source integrity is tracked through manifest files in SOURCES/. Maintainers should treat those manifests as the authoritative record of expected upstream inputs for the package. (github.com)

Source storage and integrity policy

NiceOS keeps the repository lightweight by storing packaging metadata and manifests rather than large upstream tarballs. This means:

• the Git history stays manageable
• the package can reference upstream inputs without committing bulky archives
• source verification happens through the manifest entries under SOURCES/

Before relying on an update, maintainers should verify that the manifest still matches the intended upstream source set and that no additional unpacked files need to be refreshed. Do not assume the contents are correct only because the build succeeds.

NiceOS maintenance notes

Before updating this package, check the following:

• confirm the upstream release or revision being packaged is the intended one
• compare any packaging patches against the current upstream behavior
• review whether build-system files need regeneration in a clean environment
• verify that the manifest entries in SOURCES/ point to the correct upstream inputs
• check whether the spec file still reflects the upstream build system and install paths
• review any changes in command names, compat symlinks, or man-page coverage if the package uses them
• consider whether filesystem-related changes could affect image creation, repair behavior, or test expectations

Risks to consider during updates:

• behavior changes in file-system tools may affect recovery or image-creation workflows
• regenerated build files may differ from what the package currently expects
• test suites may require extra host tools or filesystem features in the build environment
• changes in upstream layout may require spec or patch adjustments

Build and verification checklist

For RPM maintenance, a practical update check should include:

• review the upstream changelog or release notes
• verify the source manifest in SOURCES/
• rebuild in a clean mock or equivalent build environment
• confirm the package installs the expected binaries and man pages
• run the upstream test suite when practical
• inspect build logs for Autotools or generated-file issues
• verify no unexpected files were introduced into the payload
• compare package metadata and file lists against the previous build
• check that any distro patches still apply cleanly and still make sense

References

• Upstream project on GitHub

Russian documentation

• README_RU.md

Dist-git repository notes

• Package repository: rpms/dosfstools
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.