Add iflag=fullblock to dd by svlv · Pull Request #355 · megastep/makeself

svlv · 2026-01-12T11:13:09Z

rust-coreutils’ dd implementation tends to perform partial writes, which leads to partial reads and data loss as a result. Strictly speaking, without the fullblock option there is no guarantee that full blocks will be read. Even with GNU dd, partial reads and writes can occur, although they hardly ever happen.

Note

Improves archive extraction reliability by using dd’s full-block reads when supported.

In MS_dd, detect support for iflag=fullblock and, if available, pass it to the dd invocation used for block copying
Fallback behavior remains unchanged when iflag=fullblock isn’t supported

^{Written by Cursor Bugbot for commit f37330b. Configure here.}

rust-coreutils’ dd implementation tends to perform partial writes, which leads to partial reads and data loss as a result. Strictly speaking, without the fullblock option there is no guarantee that full blocks will be read. Even with GNU dd, partial reads and writes can occur, although they hardly ever happen.

gemini-code-assist · 2026-01-12T11:13:21Z

Summary of Changes

Hello @svlv, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the reliability of dd operations within the makeself-header.sh script. By introducing the iflag=fullblock option, it mitigates the risk of partial reads and writes, which can lead to data corruption or loss, thereby improving the integrity of data handling during file operations.

Highlights

Enhanced dd command reliability: The iflag=fullblock option has been added to dd commands within makeself-header.sh to ensure full block reads and prevent partial writes, addressing potential data loss issues.
Feature detection for dd: The script now includes a feature test to verify if the dd utility supports the iflag=fullblock option before attempting to use it.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

gemini-code-assist

Code Review

This pull request aims to improve the reliability of dd operations by using the iflag=fullblock option, which is a commendable goal for ensuring data integrity. However, the current implementation has a critical flaw in its feature detection logic. The test for iflag=fullblock is combined with conv=sync, but these two flags are incompatible in GNU dd. This incompatibility causes the feature detection to fail on systems with GNU dd, meaning the new, improved code path is never executed. I have provided a specific comment with a suggested fix for the test condition to ensure the change works as intended across different environments.

gemini-code-assist · 2026-01-12T11:16:06Z

-    # Test for ibs, obs and conv feature
-    if dd if=/dev/zero of=/dev/null count=1 ibs=512 obs=512 conv=sync 2> /dev/null; then
+    # Test for ibs, obs, fullblock and conv feature
+    if dd if=/dev/zero of=/dev/null count=1 ibs=512 obs=512 iflag=fullblock conv=sync 2> /dev/null; then


The iflag=fullblock and conv=sync options are incompatible in GNU dd. Your test dd ... iflag=fullblock conv=sync will fail on systems with GNU dd by returning a non-zero exit code. Since stderr is redirected to /dev/null, the if condition will silently evaluate to false, and the else branch will be taken. This renders your change to use iflag=fullblock ineffective on platforms using GNU coreutils.

To fix this, you should test for conv=sync and iflag=fullblock in separate dd commands joined by &&.

Suggested change

if dd if=/dev/zero of=/dev/null count=1 ibs=512 obs=512 iflag=fullblock conv=sync 2> /dev/null; then

if dd if=/dev/zero of=/dev/null count=1 ibs=512 obs=512 conv=sync 2>/dev/null && dd if=/dev/zero of=/dev/null count=0 iflag=fullblock 2>/dev/null; then

megastep · 2026-01-12T11:57:15Z

Thanks for this. I think Gemini has a good point there, also wondering why the NetBSD tests are failing. There's a possibility this is unrelated as the VM for this platform has been pretty flaky for a while, though it seems to actually fail with checksums not matching.

svlv · 2026-01-12T12:16:46Z

Hm, I haven't found any incompatibility with using both iflag=fullblock and conv=sync, neither in the GNU dd source code nor in its documentation. It should be fine using them for such a test.

I'll try to check what can be wrong on NetBSD.

svlv · 2026-01-12T13:36:49Z

@megastep

I’ve set up a fresh VM running NetBSD 10.1 and managed to reproduce the issue.

iflag=fullblock is not supported on NetBSD 10.1:

dd if=/dev/zero of=/dev/null iflag=fullblock
dd: unknown iflag fullblock.

There is a fallback in MS_dd(), so this case should be handled correctly. However, I then realized that MS_dd() is not used by default; it is only used when the --noprogress option is passed. When running with this option, MS_dd() is used and the test passes on NetBSD.

Currently installation on NetBSD is broken by this change svlv@51e7299. After reverting it the test passed.

Anyway, I’ll slightly modify my proposed changes.

svlv · 2026-01-12T17:42:43Z

Seems dd on NetBSD doesn't work as expected when count=0 is passed

megastep · 2026-01-12T22:37:54Z

Tests are still failing on NetBSD...

svlv · 2026-01-13T07:36:14Z

Tests are still failing on NetBSD...

Yes, as I mentioned previously, tests are failing on NetBSD due to the fix 51e7299. After reverting it, the test passed on my VM running NetBSD.

skip=1 count=0 doesn't work correctly on NetBSD. It can be reproduced in this way:

# printf "1234" | { dd bs=1 skip=1 count=0; dd bs=1 ; }
0+0 records in
0+0 records out
0 bytes transferred in 1768289253.703 secs (0 bytes/sec)
12344+0 records in
4+0 records out
4 bytes transferred in 0.001 secs (4000 bytes/sec)

4 bytes transferred, not 3, as it should be.

So, it is not related to this PR.

cursor

This PR is being reviewed by Cursor Bugbot

Details

You are on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle.

To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

megastep · 2026-01-13T09:46:40Z

@svlv Good point, I have reverted that commit and everything passes now.

svlv · 2026-01-13T10:12:35Z

From my point of view, that fix was correct, however, it does not work with dd on NetBSD.
I am not promising anything, but I will try to investigate what is wrong there.

megastep · 2026-01-13T10:29:37Z

From my point of view, I'd rather maximize the compatibility across all platforms, as evidenced by the test results, so unless we can add a test that can prove where that fix made an actual difference instead of just breaking NetBSD support, I'd rather keep it that way. I'll merge your PR.

gemini-code-assist Bot reviewed Jan 12, 2026

View reviewed changes

megastep self-assigned this Jan 12, 2026

megastep added the enhancement label Jan 12, 2026

Add check for iflag=fullblock

bdc0e9c

Merge branch 'master' into add-fullblock

f37330b

cursor Bot reviewed Jan 13, 2026

View reviewed changes

Comment thread makeself-header.sh

Initialize the iflag variable with an empty string

086f615

megastep self-requested a review January 13, 2026 10:43

megastep approved these changes Jan 13, 2026

View reviewed changes

megastep merged commit ba88ffb into megastep:master Jan 13, 2026
12 checks passed

	if dd if=/dev/zero of=/dev/null count=1 ibs=512 obs=512 iflag=fullblock conv=sync 2> /dev/null; then
	if dd if=/dev/zero of=/dev/null count=1 ibs=512 obs=512 conv=sync 2>/dev/null && dd if=/dev/zero of=/dev/null count=0 iflag=fullblock 2>/dev/null; then

Uh oh!

Conversation

svlv commented Jan 12, 2026 • edited by cursor Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gemini-code-assist Bot commented Jan 12, 2026

Summary of Changes

Highlights

Footnotes

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist Bot Jan 12, 2026

Choose a reason for hiding this comment

Uh oh!

megastep commented Jan 12, 2026

Uh oh!

svlv commented Jan 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

svlv commented Jan 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

svlv commented Jan 12, 2026

Uh oh!

megastep commented Jan 12, 2026

Uh oh!

svlv commented Jan 13, 2026

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

This PR is being reviewed by Cursor Bugbot

Uh oh!

Uh oh!

megastep commented Jan 13, 2026

Uh oh!

svlv commented Jan 13, 2026

Uh oh!

megastep commented Jan 13, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

svlv commented Jan 12, 2026 •

edited by cursor Bot

Loading

svlv commented Jan 12, 2026 •

edited

Loading

svlv commented Jan 12, 2026 •

edited

Loading