Control: tags -1 + patch [Klee Dienes] > You make a good point about ELIBACC not being in the list of errors > from open(). But then again, neither is EFAULT.
Good point. In that case, I guess it do not make much difference which non-standard fault is returned, and ELIBACC is just as good as EFAULT. Here is a draft patch to consider for the package maintainer and upstream. diff --git a/debian/patches/open-elibacc.patch b/debian/patches/open-elibacc.patch new file mode 100644 index 0000000..c68a081 --- /dev/null +++ b/debian/patches/open-elibacc.patch @@ -0,0 +1,28 @@ +Description: Use ELIBACC instad of EFAULT when open() fail. + This might make it less confusing when a race condition cause + eatmydata to fail. +Author: Petter Reinholdtsen <p...@debian.org> +Bug-Debian: https://bugs.debian.org/733274 +Forwarded: no +Last-Update: 2024-12-04 +--- +--- libeatmydata-131.orig/libeatmydata/libeatmydata.c ++++ libeatmydata-131/libeatmydata/libeatmydata.c +@@ -183,7 +183,7 @@ int LIBEATMYDATA_API open(const char* pa + /* If we get called recursively during initialization (which should + * be rare but might happen), just fail. */ + if (init_running > 0) { +- errno = EFAULT; ++ errno = ELIBACC; + return -1; + } + +@@ -221,7 +221,7 @@ int LIBEATMYDATA_API open64(const char* + /* If we get called recursively during initialization (which should + * be rare but might happen), just fail. */ + if (init_running > 0) { +- errno = EFAULT; ++ errno = ELIBACC; + return -1; + } + diff --git a/debian/patches/series b/debian/patches/series index 6298cd5..768035e 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -3,3 +3,4 @@ tests.patch drop-debian-stuff.patch test-no-distcheck.path t64.patch +open-elibacc.patch -- Happy hacking Petter Reinholdtsen
