iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Killing a report script does not undo the writes it has already made. If the script writes straight into the file your readers open, a kill can leave that file truncated, empty, or partly updated, and the previous good report may already be gone. The reliable fix is to write the new report to a temporary file beside the target and rename it over the target only after it is complete. Readers then see either the old file or the new one, never a half-written mix. That protects against an interrupted script. It does not, by itself, protect against a power cut or machine crash, which needs extra flushing steps covered below.
This article covers Linux system-call behavior and the Node.js v22.23.3 filesystem API. Other operating systems, filesystems, and network mounts can behave differently, and the guarantees described here should not be assumed to carry over.
What a kill does and does not undo
When a process is terminated, the kernel keeps every write it has already accepted. The Linux write(2) manual states the key limit plainly: “A successful return from write() does not make any guarantee that data has been committed to disk.” A successful write means the kernel took the bytes, not that they are safely on storage.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsTwo more details matter when a script is stopped in the middle of output:
#1 Best Overall
- MADE FOR THE MAKERS: Create; Explore; Store; The T7 Portable SSD delivers fast speeds and durable features to back up any endeavor; Build your video editing empire, file your photographs or back up your blogs all in an instant
- SHARE IDEAS IN A FLASH: Don’t waste a second waiting and spend more time doing; The T7 is embedded with PCIe NVMe technology that brings fast read and write speeds up to 1,050/1,000 MB/s¹, making it almost twice as fast as the T5
- ALWAYS MAKE THE SAVE: Compact design with massive capacity; With capacities up to 4TB, save exactly what you need to your drive – from large working files to game data and everything in between
- ADAPTS TO EVERY NEED: Whether using a PC or mobile phone, count on the T7 for extensive compatibility²; It’s a true team player when it comes to heavy-duty application usage or file-saving
- HI RESOLUTION VIDEO RECORDING: Record Ultra High Resolution (4K 60fs) videos directly onto the T7 Portable SSD with your favorite camera or mobile devices; Supports iPhone 15 Pro Res 4K at 60fps video and more³
- Short writes are normal. write(2) can return after writing fewer bytes than requested. A signal can interrupt the call before any bytes are written, or after some of them are.
- Buffered bytes stay in the process. Anything still held in the program’s own buffers when the process dies never reaches the file.
The result is that the file on disk reflects exactly how far the script got, which may be nothing at all.
How a direct write leaves a broken report
The most common pattern writes the report straight to its final name. A typical sequence looks like this:
Rank #2
- Get NVMe solid state performance with up to 1050MB/s read and 1000MB/s write speeds in a portable, high-capacity drive(1) (Based on internal testing; performance may be lower depending on host device & other factors. 1MB=1,000,000 bytes.)
- Up to 3-meter drop protection and IP65 water and dust resistance mean this tough drive can take a beating(3) (Previously rated for 2-meter drop protection and IP55 rating. Now qualified for the higher, stated specs.)
- Use the handy carabiner loop to secure it to your belt loop or backpack for extra peace of mind.
- Help keep private content private with the included password protection featuring 256‐bit AES hardware encryption.(3)
- Easily manage files and automatically free up space with the SanDisk Memory Zone app.(5). Non-Operating Temperature -20°C to 85°C
- Open
report.csvfor writing. Opening with truncation discards the old contents at this moment, before any new data exists. - Write the report in one or more chunks.
- Close the file.
If the process is killed at step 2, the file holds only the chunks written so far, and the previous version cannot be recovered from the file itself. The outcome depends on timing:
Recommended Free Tools
- Killed before the open with truncation: the old report is intact.
- Killed after truncation but before the first chunk: the file is empty.
- Killed partway through the chunks: the file is truncated, and a reader may parse it as a shorter, valid-looking report.
- Killed after the last chunk but before close: the content may be complete in the kernel, but completeness is still not a durability guarantee.
None of these outcomes is something you can promise in advance. The safe assumption is that a direct write can expose a partial file at any point after truncation.
Rank #3
- Plug-and-play expandability
- SuperSpeed USB 3.2 Gen 1 (5Gbps)
The replacement pattern: stage, close, rename
The fix separates building the new file from publishing it. The new report is written under a temporary name, and the public name is switched only once the new file is complete.
Step by step
- Put the temporary file in the same directory as the target. A rename is an atomic namespace switch only when source and destination are on the same filesystem. Cross-filesystem renames fail on Linux (the rename(2) call returns
EXDEV), so a temporary file in/tmpwill not work for a report in another mount. - Give the temporary file a unique name. Two runs writing at the same time should not share a staging path. A random suffix is enough for most scripts.
- Set the permissions on the temporary file explicitly. After the rename, the target takes the temporary file’s mode and metadata, not the old report’s. If the old file had group-readable permissions, the new one must have them too.
- Write everything, then close the file and check for errors. Do not rename until the write and close have both succeeded.
- Rename the temporary file over the target. On a single filesystem, readers see the old name point to the old file until the rename, and the new complete file afterward.
- If anything fails before the rename, delete the temporary file. The target is untouched, so the previous report stays in place.
Node.js v22.23.3 implementation
The following function stages the report in the target’s directory and renames it into place. The temporary file is written with flush: true, which asks Node.js to call fsync after a successful write.
Rank #4
- Easily store and access 2TB to content on the go with the Seagate Portable Drive, a USB external hard drive
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop
- To get set up, connect the portable hard drive to a computer for automatic recognition no software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
import { writeFile, rename, unlink } from 'node:fs/promises';
import { randomUUID } from 'node:crypto';
import path from 'node:path';
async function replaceReport(target, contents) {
const tmp = path.join(
path.dirname(target),
`.${path.basename(target)}.${randomUUID()}.tmp`
);
try {
await writeFile(tmp, contents, { mode: 0o644, flush: true });
await rename(tmp, target);
} catch (err) {
await unlink(tmp).catch(() => {});
throw err;
}
}Several Node.js details shape how this code should be used:
Free tools Windows power users keep installed
One-click scans. No signup required.
- Passing a file path to
fs.writeFilereplaces an existing file. That is why it cannot be used on the final path if you need atomic visibility. flushdefaults tofalse. When set totrueand the data is written successfully, Node.js usesfsync. It does not make a multi-step replacement atomic, and the rename is still what makes the switch visible.- Cancelling a write with an
AbortSignalis best effort. The Node.js v22.23.3 documentation states: “Cancelation is “best effort”, and some amount of data is likely still to be written.” An aborted write to the temporary file is harmless; an aborted write to the target is not. - The file-descriptor form of
writeFiledoes not replace the file. It writes from the descriptor’s current position, so it cannot be used to swap in a new report.
Visibility is not durability
The temporary-file pattern guarantees that a reader will not see a partial file after a process stop. Surviving a power loss or kernel crash requires two additional steps. The Linux fsync(2) manual says the call transfers modified in-core data of the file to storage so it can be retrieved after a system crash or reboot. It does not necessarily make the directory entry for that file durable. The Linux kernel filesystem documentation warns that without explicit synchronization, a system crash can leave unexpected contents.
Best Value
- NEARLY 2X FASTER THAN OUR PREVIOUS GENERATION(8) – move 1,000 high-res photos in under 60 seconds(6) with up to 2000MB/s transfer speeds(2).
- IP65 RATING AND UP TO 3M DROP PROTECTION(3) – protects against spills and drops.
- POCKET-SIZED – fits easily in pockets and small bags.
- SPACE TO OWN YOUR AI CONTENT – speed and capacity to download your high-res clips and photo edits.
- 256-BIT AES ENCRYPTION(4) – helps keep private files secure with password protection.
For power-loss safety on a Linux system that supports directory descriptors, the sequence is:
- Write the temporary file and call
fsyncon it, so its data is on storage before it is published. - Rename the temporary file over the target.
- Open the containing directory and call
fsyncon that directory descriptor, so the new directory entry is recorded on storage.
Skipping the directory sync can leave the old name in place after a crash even though the new file’s data was flushed. Keep the scope of this claim narrow: it is documented for Linux, and other platforms need their own documentation.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Comparing the strategies
| Property | Direct write to final path | Temporary file, then rename | Temporary file, fsync, rename, directory fsync |
|---|---|---|---|
| What a reader sees if the process is killed mid-write | Empty, truncated, or partly updated file | Old complete file or new complete file | Old complete file or new complete file |
| Previous report after a kill | Lost once truncation has happened | Intact until the rename | Intact until the rename |
| Filesystem requirement | None beyond writing the target | Temporary file must be on the same filesystem as the target | Same as the middle column |
| Survives a power loss or machine crash | Not guaranteed | Not guaranteed; the source does not establish this for the rename alone | Guarantees depend on the Linux fsync steps above; other platforms not established |
| Extra code | None | Temporary naming, error handling, cleanup | Adds an fsync on the file and on its directory |
Choose by the requirement that matters most. If an occasional missing report is acceptable and the script can simply be rerun, direct writing is the simplest option. If readers must never encounter a partial file, use the temporary-file rename. If the report must also survive a power cut, add the fsync steps as well.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Quick Recap
Limits and troubleshooting
- Killed processes cannot clean up. A
SIGKILLcannot be caught, so thecatchblock in the example never runs. A killed run can leave a stale temporary file behind. The target is still intact, but the stale file takes up space. Remove files matching the temporary-name pattern on the next run. - Concurrent writers need coordination. Unique temporary names prevent two runs from sharing a staging file, but they do not decide which run’s report should win. That policy belongs in the application.
- Platform scope. The behavior described here is documented for Linux system calls and the Node.js v22.23.3 API. Windows API behavior, network-filesystem guarantees, and cross-platform replacement semantics are not covered and should be checked against each platform’s own documentation.
- A report already truncated by a kill cannot be recovered from the file. Restore it from a backup or version control if one exists, or regenerate it by rerunning the script.
)
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
