OZFA Disk Control v1.7.0

An advanced disk operations release. Drives can now be asked to erase themselves in firmware — ATA Secure Erase, NVMe Sanitize, NVMe Format — and every drive can be asked what it supports before anything is offered. The erase path is the existing destructive path with more gates on it, not a second one beside it.

Secure erase / sanitize

A new workflow on the Tools page, and Secure Erase / Sanitize… on the device context menu. Five methods: ATA Secure Erase, ATA Enhanced Secure Erase, NVMe Sanitize (Crypto Erase), NVMe Sanitize (Block Erase) and NVMe Format (cryptographic erase), each issued through the interface Windows documents for it.

Every method is listed for every drive, and one that cannot be used says why in the drive's own terms: security-frozen by the firmware at start-up, a password already set, locked, attempts exhausted, the sanitize action not supported, a controller that may hold other namespaces, a sanitize already running, a Windows build too old, or a drive behind a USB bridge. A drive whose identify data could not be read is offered nothing, with the reason.

The same checks as every other destructive workflow apply unchanged — a disk the running Windows depends on is refused as PROTECTED, the device is re-identified before the run and before every write step, the typed phrase is required, and needing administrator rights is reported separately with an offer to restart elevated. Two gates are added:

• The drive's erase-relevant state is read again immediately before the erase command, after the disk is dismounted. A drive that became frozen, acquired a password or started a sanitize of its own is refused.
• One erase at a time. A second erase while one is running is refused, never queued.

Nothing works around a drive's security. There is no unlock, no master-password attempt and no removal of a password OZFA did not set, and no erase is ever sent through a USB bridge.

Checked afterwards, recorded as checked

A command that returned is not treated as an erased drive. Blocks at the start, middle and end are sampled and hashed before the erase (the data is never kept); afterwards the drive is re-identified, its own erase state read back, the partition table looked for, and the same blocks compared. The result — all checks passed, partially verified, command completed; not independently verified, verification failed or not verified — is stored with every check's finding in the operation history, and each erase has a printable record (preview, PDF, JSON, CSV) that states it is a record of what the drive reported and what was read back, not a certificate.

Drive capabilities and adapters

• Properties › Drive capabilities: protocol, path to the drive, SMART support and whether a health reading was obtained, TRIM/UNMAP, media, ATA Security state, sanitize and format support, namespaces, and every erase method with its availability or reason — read with queries that cannot change the drive. Copy troubleshooting puts it on the clipboard.
• Diagnostics › Drive capabilities and adapters: a per-drive report explaining why SMART, identity, Secure Erase and Sanitize are or are not available, including what is known about the USB bridge in front of it.
• USB adapter catalogue, revision 2: thirteen new entries identified by USB vendor and product id, including the USB-to-NVMe bridges. An adapter that is not listed is still explained and handled exactly as before.

Fixed

• Report tables in the on-screen preview showed their headings and no rows. PDF, JSON and CSV exports were unaffected.
• The Tools page could discard a reviewed plan, or the result of a finished run, on its own.

⚠ Not yet verified on hardware

No erase command has been sent to a drive by this build. The capability queries were run against real NVMe drives; the erase commands themselves, like every real format and repartition before them, have only been executed against a test backend. The Tools page says so when a real run is chosen, and every erase record says so. Validate on a drive you can afford to lose before relying on it.

Downloads

Two editions, built from one publish of the same code. The Setup installs normally and keeps its data under %LOCALAPPDATA%; the Portable archive keeps everything in a Data folder beside the executable. Both are self-contained — no .NET installation required. The history database moves to schema version 8 (new columns only); an older build refuses a newer database rather than misreading it.

SHA256SUMS.txt lists the SHA-256 of both files. The release is not code-signed.

OZFA Disk Control v1.6.0

A disk-management release. Everything needed to prepare a disk was already here, and it took a page, two dropdowns, a review, a typed phrase and a mode switch to reach. This release makes the common case one menu entry and one confirmation, and leaves every check that stands behind it exactly where it was.

Quick Format Disk

Right-click a device and read one confirmation. It names the physical disk number, model, serial and capacity, lists every partition it is about to destroy with its letter, label, file system and size, states what will exist afterwards, and shows the steps. Below all of it is one checkbox — I understand that all data and partitions on this disk will be deleted — and the button stays dead until it is ticked.

Then every partition is removed, a fresh partition table is written, one partition is created across the whole disk and quick-formatted, and the device list is re-read.

No phrase is typed, and nothing was relaxed to achieve that. A disk the running Windows depends on is still refused outright. A device whose identity cannot be established is still refused as ambiguous. The machine is still re-enumerated immediately before the run and the device re-identified before every write step, so a disk that has been unplugged, renumbered or swapped for another one stops the operation rather than being followed. A drive showing failing media still raises its own separate acknowledgement. Administrator rights are still reported separately from protection, in different words, with an offer to restart elevated.

The acknowledgement is the complete confirmation for this workflow: it never asks for a phrase, whatever the confirmation level in Settings is set to. That setting continues to govern every other destructive workflow.

Disk management where you look at it

• Context menus on devices and on partitions — Open, Properties, Quick Format Disk, Initialize, Create / Delete / Format Partition, drive letters, volume label, Online / Offline. An entry that is not valid for the selection is disabled and keeps the reason on hover rather than disappearing, and a right-click selects the row it lands on so the menu can never act on a different device than the one on screen.
• A Partitions page that accounts for the whole device — partition style, capacity, partition count, allocated, unallocated and online state as a summary line, then a proportional map, then a table in which unallocated space is a row like any other.
• Properties — a read-only window with every identifier the application holds for a device, its layout, and the selected partition and volume.
• Settings › Quick format — partition style, file system, allocation unit, volume label and drive letter, restated as one sentence, because these are not shown again at the moment they are applied.

⚠ Real destructive execution is still not verified on hardware

Planning, the protection verdict, the target re-identification, the confirmation flow and the audit trail are complete and covered by tests, including every refusal Quick Format can produce. What has never run is a Windows storage call that actually changes a partition table — every disk on the development machine holds real data and is protected. The application says so on the Tools page and in the Quick Format dialog. Treat a real run as unproven, and use a disk you can afford to lose.

Downloads

Two editions, built from one publish of the same code. The Setup installs normally and keeps its data under %LOCALAPPDATA%; the Portable archive keeps everything in a Data folder beside the executable. Both are self-contained — no .NET installation required.

SHA256SUMS.txt is attached. The release is not code-signed, so SmartScreen will warn that the publisher is unrecognised; verify the checksum, then choose More info → Run anyway.

Health data (health percentage, SMART table, temperature, SSD wear) requires your own licence of Hard Disk Sentinel Professional, a separate commercial product that is not bundled or redistributed here. Everything else works without it.

Full notes: CHANGELOG.md · Install guide: docs/INSTALL.md

OZFA Disk Control v1.5.0

A technician-workflow release. The bench is the place this application is actually used, and until
now it only ever looked at one disk at a time.

Added

• Bench Mode. Select several attached devices and run read-only checks across all of them in
  one pass: a health and SMART snapshot, a quick read check, a surface read scan and a sequential
  read benchmark. Results fill into the same list that was ticked, one row per device, with the
  real model, the serial where the device reported a trustworthy one, health, temperature, the
  checks performed, how long each took, and a Pass / Warning / Fail verdict with the sentence
  behind it.

  Bench Mode cannot write to a disk. That is structural rather than a default: the batch path
  has no way to express a destructive step. Erasing, partitioning and formatting stay on the Tools
  page, one device at a time, behind the planner, the target check and the typed confirmation —
  selecting six drives at once is the worst possible moment to make a write one click easier.

• Scheduling that does not saturate one cable. Four drives in a dock look like four independent
  devices and are, for everything except bandwidth: they reach the machine through one USB link.
  Reading them together produces four throughput figures that are each a quarter of the truth and
  four surface scans whose slow blocks are the other three drives' fault. Devices are grouped by
  the adapter or hub they share and worked through one at a time; independent devices run together,
  up to a configurable number of groups. Grouping applies only when a throughput measurement was
  selected — a quick check cannot be distorted by contention, only slightly slowed. When the device
  tree cannot be read, external devices are treated as sharing one link, which is the conservative
  reading, and the page says so.

• Work orders. A ticket number, a customer reference and technician notes can be attached to a
  bench session and to any device in the Library. They are printed on the bench summary, stamped on
  to test results and disk-operation audit entries as they happen, and searchable from the Library
  box. All three are free text a person typed: nothing is looked up anywhere.

• A printable bench summary. A finished pass opens as a document with the session, the job, the
  outcome counts, a device table, a table of every check with the range and block size its numbers
  came from, and the findings behind each verdict. It goes through the same preview and the same
  PDF, JSON and CSV writers as a single-device report, and every block is labelled as measurement
  or as interpretation. Past sessions can be reopened and printed again.

• Trend analysis over stored inspections. The History page gains a "Direction of travel" panel
  that reads the whole stored range rather than the last two inspections: which way health,
  reallocated, pending, weak and bad sectors have moved, over how many readings and what period.

  It says "not enough evidence" readily. Two readings an hour apart are reported as what was seen
  and carry no rate; a rate per thirty days is only computed once the readings span more than a
  day, and a direction is only called settled at four readings over a week. Current state and
  historical trend are always two separate statements, because "three pending sectors" and "pending
  sectors have gone from zero to three since March" lead to different decisions. Nothing is
  extrapolated — there is no projected failure date and no remaining-life estimate of this
  application's own making anywhere in the feature.

• A versioned USB adapter catalogue. Keyed by the USB vendor and product ids read from the
  device tree, which are assigned by USB-IF and burned into the bridge, unlike the SCSI strings
  further down the stack that an enclosure vendor rewrites freely. It explains why a device looks
  the way it does — a bridge that answers with its own name, a serial that is absent or shared
  across units, a bridge that does not pass SMART through — and records whether each entry was
  observed on hardware by this project or is expected from the bridge family.

  It never relaxes a rule. Every behaviour it describes was already handled generically, and an
  adapter that is not listed behaves exactly as it did before the catalogue existed. Its version is
  stamped on every bench session so a note on an old summary can be traced to what the store said
  at the time.

• "Always start OZFA Disk Control as administrator", off by default. Everything except disk
  management works unelevated, and the disk tools already offer to restart elevated at the moment
  they need to, so off stays the recommendation. On a dedicated bench machine a consent prompt at
  startup beats one in the middle of a job. It cannot loop: it does nothing when the process is
  already elevated, nothing when the launch is itself the result of an elevation request, and
  nothing on a sign-in launch, where there would be nobody to answer the prompt. A dismissed prompt
  leaves the application running normally and Settings says why.

Fixed

• A disk-management plan could be sent to the wrong device if Windows renumbered it. Every
  platform call names its target by physical disk number, and a plan records the number the device
  had when it was reviewed. The check before a run correctly followed the device rather than the
  number — renumbering after a hot-plug is normal and must not block correct work — but the run
  itself still issued the old number. A plan reviewed while a drive was Disk 2 would have been
  executed against whatever held Disk 2 at that moment.

  Operations are now addressed to the identity the check re-resolved, and the target is
  re-identified immediately before every step that writes, not only before the first. A device
  pulled out between two steps of a running plan, or replaced at the same number, stops the run;
  the steps that already ran stand and the result says plainly that the device is part-way through.
  An enumeration that could not complete also stops the run, because a device list that failed to
  read is not evidence that anything is still there.

Changed

• The Library search box also matches a ticket number and a customer reference, and the entry
  editor takes both alongside the notes and tags.
• Diagnostics reports Bench Mode and the adapter catalogue's version.
• The toolbar keeps its navigation labels down to a slightly wider window, because Bench joined the
  rail. Below that it still sheds labels rather than buttons.

Still not verified on hardware

• A real format or repartition has still never been run against a disposable disk. The planner,
  the safety checks, the confirmation flow, the target re-identification and the dry run are
  complete and covered by tests, including the cases added above; what has not happened is the
  backend actually writing to metal. The Tools page says so at the moment a real run is selected,
  and will keep saying so until a disk can be sacrificed to prove it.

Downloads

File
OZFA-Disk-Control-v1.5.0-Setup.exe	Normal Windows installation. Data under %LOCALAPPDATA%\OZFA\DiskControl.
OZFA-Disk-Control-v1.5.0-Portable.zip	Unzip and run. Data, settings and logs live beside the executable.
SHA256SUMS.txt	Checksums for both files.

Both are self-contained: no .NET installation is required. Neither is code-signed, so Windows
SmartScreen will warn on first run — check the download against SHA256SUMS.txt:

Get-FileHash .\OZFA-Disk-Control-v1.5.0-Setup.exe -Algorithm SHA256

or, on Linux or Git Bash, sha256sum -c SHA256SUMS.txt.

1bcaa33ab1446bb7aa5e424465571d308ce85058a0e0e2ecec257e74152b4639  OZFA-Disk-Control-v1.5.0-Portable.zip
a5aae1b3e3f93d3b33d7bae9fadb9102d857bc19d86e9d66bf4c522a7309a310  OZFA-Disk-Control-v1.5.0-Setup.exe

Upgrading from 1.0–1.4 keeps your history, settings and disk library. The history database moves
to a newer format, so an older version will not open it afterwards. Windows 10 20H1 or later, 64-bit.

OZFA Disk Control v1.4.0

Built from shop feedback on 1.3: one hot-swap bug that 1.3 did not fully close, and the workflow
around the disks a technician is actually handling.

Fixed

• A replaced disk could still show the previous drive's health or name until Rescan. 1.3 held
  back a health record that belonged to a drive which had just been pulled, but it only remembered
  that for one refresh. In the shop the sequence is rarely one refresh: the drive is pulled, the
  application refreshes with the bay empty, and a few seconds later a different drive goes in. By
  then nothing was wearing the old record any more, so there was nothing left to hold, and Hard
  Disk Sentinel's unchanged, stale record matched the new drive by position. Pressing Rescan before
  Sentinel had looked again did not hold anything either, because the device list had not changed
  during the Rescan itself.

  A held record now stays held across any number of refreshes, manual Rescan included, until there
  is evidence that the provider has read the hardware again: it publishes a different set of
  devices, or the held record's own readings (temperature, power-on time, bytes written, SMART raw
  values) move, which can only happen when the drive answering to that record is attached. Nothing
  else releases it. A disk whose reading is being withheld says Waiting for provider rescan, and
  history and alerting skip it rather than recording "no health data" for a drive that has not been
  judged.

Known limitation

• How quickly figures appear after a swap is decided by Hard Disk Sentinel. Sentinel publishes
  no scan time and no marker for a removed drive, so a record it has not refreshed is
  indistinguishable from a current one. OZFA now refuses to show such a record rather than guess,
  but it cannot make Sentinel rescan sooner, and polling faster would not change what Sentinel
  publishes. The definitive fix is the planned native SMART/NVMe provider, which reads the drive
  itself and has no second scan schedule to wait for.

Changed

• The drive's own name is used everywhere the disk list uses it. Behind a USB dock or adapter,
  the Library, the Alerts page, alert labels and report titles now show the drive's real model and
  serial, with the enclosure named alongside. The library entry keeps what Windows reported, shows
  it as "Windows saw", and can be searched by either. Correlation, history keys and the
  verification before a destructive operation still use Windows' identity only.
• Alerts are organized by disk. The page lists devices on the left, most urgent first, with
  unread counts and the worst unread severity; selecting one shows only that disk's alerts, newest
  first, and the selected alert's full detail beneath. "All devices" keeps the chronological view.
  Alerts raised before 1.4 under an adapter's name are grouped under the drive's name.
• Disk list rows stay put during hot-swaps. Internal disks are listed first in disk-number
  order; external devices keep the row they first took, and a drive pushed into a dock bay takes the
  row of the one it replaced instead of jumping to the bottom. Internal and external headings appear
  when both kinds are attached.
• Stable and Beta update channels. Settings → Updates offers a channel; Stable is the default.
  Stable now also skips a release the publisher has marked as a pre-release, not only one with a
  pre-release version number.

Added

• Failing-media warning before destructive preparation. When a destructive plan is reviewed for
  a drive that Sentinel rates Critical, or that has pending sectors, bad sectors, or serious
  reallocations, the Tools page names each sign of failure and explains what writing to it costs.
  Neither dry run nor execution runs until the warning is acknowledged. It is a warning, never a
  refusal.
• Interrupted-operation audit. A real disk operation records its intent before it touches the
  device and replaces that entry with the result afterwards. If the application dies part-way, the
  next launch marks the entry Interrupted with the device's state unknown, and raises a critical
  alert for that disk.
• "Why no health data?" One click on Overview or Diagnostics saves a single archive with the
  provider's status, every record it published and its fields, each disk's matching verdict and the
  recent logs, and shows it in File Explorer. Serials, unique identifiers, device paths, volume
  labels, the machine name and the Windows account are replaced with consistent placeholders before
  anything is written.
• Match confidence on the disk list. Health figures attached on limited evidence — a model and
  capacity resemblance, or the provider's device number behind an adapter — carry a small ≈ marker
  whose tooltip gives the reason.

Release

• SHA256SUMS.txt is written with LF line endings, so sha256sum -c works on Linux and Git Bash.
  Checksum files for 1.0.0–1.3.0 are unchanged.
• The history database moves to schema version 6 (new columns only). An older build refuses a
  newer database rather than risk it, so after running 1.4 a 1.3 installation will not open the
  same history.

Not verified on hardware

• The hot-swap hold and the stable row order are tested against constructed machines that
  reproduce the reported sequences, including a removal and an insertion in separate refreshes and
  a Rescan pressed in between. They have not been run against a real dock with Hard Disk Sentinel
  running: the development machine has no USB-to-SATA adapter.
• No real format or repartition has been executed against a disposable disk. Unchanged since
  1.2: planning, the safety checks, the confirmation flow, the dry run and now the intent audit are
  complete and tested; the moment the backend writes has only been exercised against a test
  backend, and the Tools page still says so.
• Secure Erase and NVMe Sanitize are not included.

Downloads

File
OZFA-Disk-Control-v1.4.0-Setup.exe	Normal Windows installation. Data under %LOCALAPPDATA%\OZFA\DiskControl.
OZFA-Disk-Control-v1.4.0-Portable.zip	Unzip and run. Data, settings and logs live beside the executable.
SHA256SUMS.txt	Checksums for both files.

Both are self-contained: no .NET installation is required. Neither is code-signed, so Windows
SmartScreen will warn on first run — check the download against SHA256SUMS.txt:

Get-FileHash .\OZFA-Disk-Control-v1.4.0-Setup.exe -Algorithm SHA256

or, on Linux or Git Bash, sha256sum -c SHA256SUMS.txt.

7dcb32060de390211be2cd85f085da5da2d1b16b78f855aa8bb2cd51a6c46842  OZFA-Disk-Control-v1.4.0-Portable.zip
6f62b67251e18de7b0d5d8163345dce132bf2241378cc6d6a16b4c3622b37833  OZFA-Disk-Control-v1.4.0-Setup.exe

Upgrading from 1.0–1.3 keeps your history, settings and disk library. The history database moves
to a newer format, so an older version will not open it afterwards. Windows 10 20H1 or later, 64-bit.

OZFA Disk Control v1.3.0

Two problems found using 1.2 on the bench, one of them serious.

Fixed

• A swapped-in disk could briefly show the health of the disk it replaced. With two drives in a
  dock, taking both out and putting two different ones in produced, for a few seconds, the old
  drives' health figures sitting under the new drives. A manual Rescan corrected it.

  Three things lined up to cause it. Windows publishes the new devices within a second or two and
  hands them the disk numbers the old ones had. Hard Disk Sentinel scans on its own schedule, so it
  is still describing the drives that were pulled out — and nothing inside those records marks them
  as stale, because every field in them is a real reading of real hardware. And a dock that answers
  for its drives gives both bays the same product string and no serial, which leaves the health
  provider's own device numbering as the only thing left to match on. Correct evidence, correct
  numbering, wrong drives.

  The application now keeps track of which health record it put on which disk, and of exactly what
  the provider was publishing at the time. When the machine changes — the device list differs, or
  Windows reports a storage arrival or removal — a record that a disk was wearing before the change
  is held back for as long as the provider's output has not moved, because output that has not moved
  is a provider that has not looked again. While anything is held back, matching a disk by the
  provider's device number is switched off entirely, since position is precisely the evidence that
  goes wrong across a swap.

  Holding a record back is not throwing it away: a serial or a unique identifier agreeing is proof
  the same device is back, and proof still wins. A drive unplugged and plugged into another port
  keeps its own reading, and so does every disk that reports a serial of its own. The hold is
  scoped to records worn by a disk that is either gone or indistinguishable from a replacement —
  a machine's internal disks are not affected by a USB stick being plugged in.

  Every state the application publishes now carries a number identifying the set of devices it
  describes, and a state describing a set that has already been replaced is dropped rather than
  displayed. That closes the last gap: an answer about the previous machine arriving after the new
  one is on screen.

• A disk being waited on now says so, instead of reporting no health data. "No health data" is a
  verdict about a drive. A device attached three seconds ago that is still being asked about has not
  earned one, and a technician who reads it as a verdict puts a working disk on the reject pile.
  Those devices now read Detecting health data… until the answer arrives or the attempt is over.

Changed

• The wait for a health provider to catch up is longer, and it starts after a swap as well as
  after an arrival. What is really being waited on is the provider's own scan interval, which is
  measured in tens of seconds, so the backoff now runs nine attempts across a minute rather than
  five across nineteen seconds, and stops the moment the answer arrives. It re-asks the provider,
  not the machine: discovery is not re-run, a device that has been attached for a while is never
  re-asked about, and the retry is abandoned outright if the machine changes underneath it. When it
  ends without an answer, the device reports no health data — which by then is the truth.

  History capture and alerting continue to sit the wait out, so a reading that was merely late does
  not become a "health data disappeared, then came back" pair in a disk's history or an alert about
  nothing.

• Disks behind a USB adapter are now named after the drive even when the adapter's name looks
  plausible. In 1.2 the drive's real model was substituted only when what Windows reported was
  obviously not a model — empty, numeric, or a bridge chipset's name. That missed the case this was
  reported for: the same two-bay dock passes both real models through with two disks in it, and
  reports its own perfectly ordinary-looking product name with one disk in it. "Does the Windows
  name look plausible" is therefore not a usable test.

  Where a health record has been correlated to a device behind an enclosure and that record names
  real media, the record now wins — it was read from the drive, while Windows read whatever answered
  on the bus. The one exception is a provider model that is merely a shortened form of the one
  Windows already has, since providers routinely clip the field (Hard Disk Sentinel stops at
  twenty-five characters) and trading a complete name for a truncated one describing the same drive
  would be a loss dressed up as a fix. The enclosure is still named alongside the drive.

  Nothing about this changes which device is which: correlation, history and the check that runs
  immediately before a destructive operation all continue to use the identity Windows reported, and
  the Tools page keeps displaying that identity so a confirmation always shows the identity it is
  actually checking.

Not verified on hardware

• The stale-health fix, the retry and the adapter naming are covered by tests that reproduce the
  reported scenarios against constructed machines — including the swap where the two device lists
  are indistinguishable from each other. None of it has been run against a real dock: the
  development machine has no USB-to-SATA adapter, and Hard Disk Sentinel could not be started
  during this build, so no live correlation was exercised at all. What a specific dock publishes,
  and how long a specific Sentinel installation takes to rescan, decide what you will actually see.
• No real format or repartition has been executed against a disposable disk. Unchanged from
  1.2: planning, the safety checks, the confirmation flow and the dry run are complete and tested;
  the moment the backend writes has only ever been exercised against a test backend.

Downloads

File
OZFA-Disk-Control-v1.3.0-Setup.exe	Normal Windows installation. Data under %LOCALAPPDATA%\OZFA\DiskControl.
OZFA-Disk-Control-v1.3.0-Portable.zip	Unzip and run. Data, settings and logs live beside the executable.
SHA256SUMS.txt	Checksums for both files.

Both are self-contained: no .NET installation is required. Neither is code-signed, so Windows
SmartScreen will warn on first run — check the download against SHA256SUMS.txt:

Get-FileHash .\OZFA-Disk-Control-v1.3.0-Setup.exe -Algorithm SHA256

fdd5a4629ed81b9839c9603789dd8ab3a5ea43d589eb15f442c0b2fae46c65de  OZFA-Disk-Control-v1.3.0-Portable.zip
1da1f64fbbbbf2831247145ca01f4921eeaff71a154f48cd8459ac695966eadf  OZFA-Disk-Control-v1.3.0-Setup.exe

Upgrading from 1.0, 1.1 or 1.2 keeps your history, settings and disk library. Windows 10 20H1 or
later, 64-bit.

OZFA Disk Control v1.2.0

Three problems found while using 1.1 on the bench. Nothing else changed.

Fixed

A secondary disk was refused simply for containing an old Windows

Protection was decided by what a disk looked like: any EFI System Partition, Microsoft Reserved
Partition or recovery partition made the whole disk untouchable. A technician's second disk is
usually a disk pulled out of another computer and carries exactly those, so the disk that most
needed erasing was the one the application would not touch.

Protection is now decided by a single question — does the Windows installation that is running
right now depend on this disk? The boot disk, the system disk, the volume Windows is running
from, any partition holding an active page file or hibernation state, and the recovery partition
Windows itself names all still protect their disk absolutely, and no confirmation unlocks them. A
partition type on a disk nothing on this machine uses no longer refuses anything: it produces a
warning naming what is about to be destroyed, including the mounted volumes and the fact that
another computer may stop starting.

The two verdicts are now said in two different sets of words, because collapsing them was half the
problem. PROTECTED means the application refuses. DESTRUCTIVE WARNING means it will proceed
and the data will be gone. Identity checking is unchanged and still fails closed: a device with no
trustworthy serial, no capacity or an unreadable partition table is refused, and the target is
re-resolved and re-judged immediately before anything is written.

Needing administrator rights was presented as though the disk were protected

Disk management requires an elevated process, and a refusal for that reason read like a safety
verdict about the drive. It is now reported as what it is, and the Tools page offers Continue as
administrator, which restarts the application elevated and reopens the same device.

The plan does not travel. Only the device's identity does — the elevated copy re-reads the machine,
re-evaluates protection, and asks for the plan to be reviewed and confirmed again, because the
device list can change while the consent prompt is on screen. Dry runs continue to work without
elevation, exactly as before.

A disk plugged in while the application was running could show "No health data"

Windows publishes a device as soon as the bus enumerates it, which for some drives is before Hard
Disk Sentinel has finished its own scan — so the disk appeared complete in every respect except its
health, and pressing Rescan a few seconds later fixed it.

The application now waits that race out by itself: for a newly connected device only, it re-asks
the health provider five times over nineteen seconds and stops the moment a reading arrives. It
re-asks the provider, not the machine — discovery is not re-run — and a device that has been
attached for a while is never re-asked about, so this can never become a permanent poll. History
and alerting sit out the wait, so a reading that was merely late does not become a "health data
disappeared, then came back" pair in the disk's history or an alert about nothing.

Changed

Disks in USB adapters are now named after the drive, not the adapter

Some adapters answer the Windows storage stack with the bridge chipset's own product string, or
with a placeholder as bare as 0, while Hard Disk Sentinel reads the drive's real identity through
the same adapter. Where a health reading has already been correlated to the device, the drive's
model — and its serial and firmware where the adapter clearly supplied neither — is what the disk
list, the header, the Overview page and the report now show, with the enclosure named alongside it.

The substitution is display only, and narrow: it happens only for a device reached through an
enclosure, only where a reading was already matched to it, and only where what Windows reported is
recognisably not a drive model and what the provider reported is. A drive that names itself is
never renamed. Everything that decides which device is which — correlation, history, and the
check that runs immediately before a destructive operation — continues to use the identity Windows
reported, and the Tools page keeps showing that identity so the confirmation always displays the
identity it is actually checking.

What has and has not been run against hardware

• The protection rules were verified on a real two-disk machine: the system and boot disk is
  refused with its dependencies named, and a secondary NVMe carrying a leftover Microsoft Reserved
  Partition and a mounted volume is now correctly allowed with a warning naming both.
• The USB-adapter identity change and the hot-plug retry are covered by tests, but no
  USB-to-SATA adapter has ever been attached to the development machine, so neither has been seen
  working against a real bridge. What a specific adapter publishes decides what you will see.
• No real format or repartition has been executed against a disposable disk. Planning, the
  safety checks, the confirmation flow and the dry run are complete and tested; the moment the
  backend actually writes has still only been exercised against a test backend. The Tools page says
  so where the choice is made. Treat a real run as unproven, and use a disk you can afford to lose.

Downloads

File
OZFA-Disk-Control-v1.2.0-Setup.exe	Normal Windows installation. Data under %LOCALAPPDATA%\OZFA\DiskControl.
OZFA-Disk-Control-v1.2.0-Portable.zip	Unzip and run. Data, settings and logs live beside the executable.
SHA256SUMS.txt	Checksums for both files.

Both are self-contained: no .NET installation is required. Neither is code-signed, so Windows
SmartScreen will warn on first run — check the download against SHA256SUMS.txt:

Get-FileHash .\OZFA-Disk-Control-v1.2.0-Setup.exe -Algorithm SHA256

8fecdeac2b2453ca8e0c0f9851ab81d31d5c01060c161a828ac66a35b54282ab  OZFA-Disk-Control-v1.2.0-Portable.zip
23d35be7b13936f67076c25861928c35ecc88d5aa121f852d7ed0b70d1e3d4f7  OZFA-Disk-Control-v1.2.0-Setup.exe

Upgrading from 1.0 or 1.1 keeps your history, settings and disk library. Windows 10 20H1 or later,
64-bit.

OZFA Disk Control v1.1.0

Health readings now correlate for disks attached through USB adapters and docks, and a sign-in launch stays in the notification area by default.

Fixed

Disks in USB adapters and docks showed "No health data". A USB-to-SATA/NVMe bridge answers the Windows storage stack on the drive's behalf and reports the serial number baked into the adapter rather than the one printed on the drive, while Hard Disk Sentinel reaches past the bridge and reports the real one. One device therefore presented two unrelated serials, and the rule that two different serials prove two different devices — correct for a directly attached disk — threw the reading away before the model or the capacity was ever looked at. That is why an external disk enumerated perfectly and still showed nothing.

Health, temperature, performance and the SMART table now appear for externally attached disks.

Safety is unchanged. A reading matched this way is labelled in the interface as matched on limited evidence, and can never authorize a format or a repartition — those still require a unique identifier. Two disks that cannot be told apart leave both readings unattached, because showing one disk's health under another disk's name would be worse than showing none.

Correlation failures are now explained in the log, naming which fields disagreed — never what they contained.

Changed

A sign-in launch now stays in the notification area by default. Asking Windows to start something when you sign in is a request for it to be watching, not a request for a window in front of whatever you signed in to do. Monitoring, history capture, alerting and hot-plug detection run exactly as before, and starting the application yourself still shows the window. An existing installation keeps whatever it was already set to.

Corrected the update and privacy documentation. The 1.0.0 notes said no update repository was configured, which was already untrue of the published build. Automatic checking is on by default and asks GitHub for this product's list of releases; it sends no machine, user or disk information, and it cannot download or install anything.

Known limitation

The USB correlation fix has not yet been confirmed against real bridge hardware — none was available on the build machine. It is covered by tests and is fail-closed by construction. If your adapter still reports no health data, the log now says which fields disagreed.

Before you install

• Advanced health, temperature and SMART data require your own licensed installation of Hard Disk Sentinel Professional, with Report status to WMI enabled in its configuration. Hard Disk Sentinel is not bundled with this application and is not distributed here. Everything else — discovery, disk identity, partitions and volumes, capacity, read tests, surface scans, benchmarks, reports, history and the disk tools — works without it.
• Real destructive execution remains unverified on hardware. The planner, the safety checks, the confirmation flow and the dry run are complete and covered by tests, but a real format or repartition has so far only been executed against a test backend. Treat a real run as unproven and use a disk you can afford to lose.
• These builds are not code-signed, so Windows SmartScreen will warn that the publisher is unrecognised. Verify the checksum below, then choose More info → Run anyway.

Verify your download

SHA-256 checksums are published as SHA256SUMS.txt with this release.

0e7c26b0b9a4a5c28b8702cd031760492bdda6775c1c79ff0c76234fb80ee8d7  OZFA-Disk-Control-v1.1.0-Setup.exe
5878fad7beb2cf15b1d36457abfe66d03e50c6dfbea71a0be72e8bb3338e01fc  OZFA-Disk-Control-v1.1.0-Portable.zip

Get-FileHash .\OZFA-Disk-Control-v1.1.0-Setup.exe -Algorithm SHA256

Which download

Setup.exe	Normal Windows installation: Start Menu entry, uninstall entry, optional sign-in start. Data lives under %LOCALAPPDATA%\OZFA\DiskControl.
Portable.zip	Unzip and run. Data, settings and logs live in a Data folder beside the executable.

Windows 10 20H1 or later, 64-bit. No .NET installation required — both editions are self-contained.

OZFA Disk Control v1.0.0

Professional disk diagnostics, history and management for Windows technicians.

The first public release. OZFA Disk Control identifies every disk properly rather than by drive
letter, reads its condition, remembers what it has seen over time, tests it without writing to it,
prepares it when you ask, and refuses to touch anything it cannot positively identify.

---

Downloads

File	What it is
OZFA-Disk-Control-v1.0.0-Setup.exe	Normal Windows installation. Start Menu and uninstall entries, optional desktop shortcut, optional sign-in start. Data lives under %LOCALAPPDATA%\OZFA\DiskControl.
OZFA-Disk-Control-v1.0.0-Portable.zip	Unzip and run. Data, settings and logs live in a Data folder beside the executable, so the whole installation travels with the folder and leaves nothing behind.
SHA256SUMS.txt	Checksums for both files.

Both are self-contained — the .NET runtime is inside the download, so nothing has to be
installed first. That is deliberate: this is a tool you reach for on a machine that is already in
trouble.

Requires Windows 10 version 2004 (build 19041) or later, or Windows 11, 64-bit.

Verify your download

Get-FileHash .\OZFA-Disk-Control-v1.0.0-Setup.exe -Algorithm SHA256

Compare the result with the matching line in SHA256SUMS.txt.

⚠ This release is not code-signed

Windows SmartScreen will warn that the publisher is unrecognised. Verify the checksum above, then
choose More info → Run anyway. Code signing is planned; until then the checksums are how you
confirm a download is genuine.

---

What is in it

• Discovery and identity — model, serial, firmware, bus, capacity, logical and physical sector
  size, kept stable across ports, renumbering and reconnection. Hot-plug detection.
• Condition — health, temperature, performance, power-on time, lifetime writes, sector counters
  and the full S.M.A.R.T. attribute table.
• History — event-driven capture per device, a searchable library of every disk this
  installation has seen, and a "what changed" comparison between any two inspections.
• Alerting — thresholds you set, duplicate suppression, and Windows notifications.
• Read-only tests — quick check, read/verify, a full surface scan with a response-time block
  map, and a sequential read benchmark with temperature measured either side.
• Disk tools — initialize, GPT/MBR, create and delete partitions, drive letters, volume labels,
  online/offline and quick format. Each one planned, checked against the safety rules, shown in
  full, and confirmed before it runs.
• Reports — a technician report per device as PDF, JSON or CSV.
• An optional shared library across your own LAN. Off by default.
• Background monitoring — closing the window puts the application in the notification area and
  keeps history capture, alerting and hot-plug detection running.
• Light and dark themes, both designed rather than inverted from one another.

---

⚠ Advanced health data requires Hard Disk Sentinel Professional

Version 1 reads the health percentage, the S.M.A.R.T. attribute table, temperature and SSD wear
from Hard Disk Sentinel Professional over WMI.

Hard Disk Sentinel is a separate commercial product by a different author. It is NOT bundled with
OZFA Disk Control, is NOT installed by it, and is NOT redistributed by it. You need your own
legitimate Hard Disk Sentinel Professional licence.

To enable it: install Hard Disk Sentinel Professional, turn on Report status to WMI in its
configuration, then press Rescan.

Everything else works without it — discovery, disk identity, partitions and volumes, capacity,
read tests, surface scans, benchmarks, reports, history of what it can see, the shared library and
the disk tools. Health readings are reported as unavailable rather than guessed at. The
Diagnostics page shows exactly what the provider returned, field by field.

---

⚠ Real destructive execution is not yet verified on hardware

The planner, the safety checks, the confirmation flow and the dry run are complete and covered by
tests. But a real Quick Format or repartition has so far only been executed against a test
backend — both disks in the development machine hold protected roles, and no disposable disk was
available to prove the final step on metal.

The application says so at the point a real run is chosen. Treat a real run as unproven, and use
a disk you can afford to lose. Dry runs exercise every step, including the safety checks, without
writing anything.

The safety rules themselves are enforced in code and covered by tests:

• The Windows system and boot disk is never a destructive target.
• EFI, reserved and recovery partitions are protected, on any disk.
• A drive letter alone never selects a target.
• Every plan is shown in full and confirmed explicitly before anything is written.
• The target is re-checked against the device immediately before execution.
• An ambiguous identity fails closed, never open.

---

Privacy

No telemetry, no analytics, no crash reporting, and no network traffic of any kind by default.

The application can make exactly two outbound connections, neither configured out of the box: the
optional shared library, to a server address you type in yourself; and the update check, to this
repository's public releases feed. The update check sends nothing but a request for the list of
releases — no identifier, no machine name, nothing about your disks — and it cannot download or
install anything. Opening a release happens in your own browser.

---

Licence

OZFA Disk Control is proprietary software. It is not open source and its source code is not
published. The compiled application is licensed for personal use and for the internal business use
of your organisation, including commercial repair work; redistribution and resale are not
permitted. See LICENSE.

Developed by KLOWZY.