You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks to a tip-off from @carlocab I did a simple test to see if eatmydata actually eats my data on macos:
eatmydata relies on DYLD_FORCE_FLAT_NAMESPACE and DYLD_INSERT_LIBRARIES, which, in my experience, no longer works on newer versions of macOS.
The trick I used relies on eatmydata (quite reasonably IMHO) not attempting to emulate the error case where the fd isn't actually syncable. So this test program behaves differently when under eatmydata vs not:
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
int main() {
int fd;
for (fd = 0; fd <= 2; ++fd) {
int r = fsync(fd);
if (r != 0) {
printf("fsync of fd %d failed: %s\n", fd, strerror(errno));
}
#ifdef __APPLE__
r = fcntl(fd, F_FULLFSYNC, 0);
if (r != 0) {
printf("F_FULLFSYNC of fd %d failed: %s\n", fd, strerror(errno));
}
#endif
}
return 0;
}
Testing on Debian unstable, using the debian eatmydata package:
This demonstrates that this error case is indeed handled differently when eatmydata is working. So far, so good.
I don't own a mac, so I tested macos using github actions - this is using the homebrew libeatmydata package which includes the patch from #33 that you kindly recently merged:
The output from ./testeatmydata < /dev/null 2> /dev/null is exactly the same with and without eatmydata:
F_FULLFSYNC of fd 0 failed: Operation not supported by device
fsync of fd 1 failed: Operation not supported
F_FULLFSYNC of fd 1 failed: Bad file descriptor
F_FULLFSYNC of fd 2 failed: Operation not supported by device
With a working eatmydata I would expect the output to differ, probably with no errors reported under eatmydata though I find F_FULLFSYNC of fd 1 failed: Bad file descriptor surprising as stdout must be open for this output to get logged - I'd guess it's a socket (fds 0 and 2 should be block devices).
I'm afraid I don't know how to fix this.
The text was updated successfully, but these errors were encountered:
Thanks to a tip-off from @carlocab I did a simple test to see if eatmydata actually eats my data on macos:
The trick I used relies on eatmydata (quite reasonably IMHO) not attempting to emulate the error case where the fd isn't actually syncable. So this test program behaves differently when under eatmydata vs not:
Testing on Debian unstable, using the debian eatmydata package:
This demonstrates that this error case is indeed handled differently when eatmydata is working. So far, so good.
I don't own a mac, so I tested macos using github actions - this is using the homebrew libeatmydata package which includes the patch from #33 that you kindly recently merged:
https://github.com/ojwb/homebrew-eatmydata-test/actions/runs/5766706912/job/15635169095
The output from
./testeatmydata < /dev/null 2> /dev/null
is exactly the same with and withouteatmydata
:With a working eatmydata I would expect the output to differ, probably with no errors reported under eatmydata though I find
F_FULLFSYNC of fd 1 failed: Bad file descriptor
surprising as stdout must be open for this output to get logged - I'd guess it's a socket (fds 0 and 2 should be block devices).I'm afraid I don't know how to fix this.
The text was updated successfully, but these errors were encountered: