El mar, 3 dic 2024 a las 12:47, Samuel Thibault
(<samuel.thiba...@gnu.org>) escribió:
>
> Yes, the current behavior is really odd, I don't see why zstd would try
> to remove /dev/zero...
>
I managed to craft a small reproducer by doing the following steps:
1. open /dev/zero
2. write something into it
3. close it
Here is the code:
---->8-------->8----
#include <errno.h>
#include <stdio.h>
#include <string.h>
int main(int argc, char ** argv)
{
FILE *file = fopen(argv[1], "wb");
fprintf(file, "Hello World!\n");
int ret = fclose(file);
printf("fclose ret: %d; err = %s\n", ret, strerror(errno));
return 0;
}
---->8-------->8----
Running it on /dev/zero gives the following result:
$ ./fclose /dev/zero
fclose ret: -1; err = Success
So while errno shows no apparent error, fclose still returns -1. That
return value triggers the remove file code path of zstd. [1]
I traced the code path using gdb and reached to this failing function
in GLIBC (_IO_file_close_it):
0x00000001012c599b in fclose () from /lib/x86_64-gnu/libc.so.0.3
=> 0x00000001012c599b <fclose+587>: e8 30 d8 00 00 call
0x1012d31d0 <_IO_file_close_it>
(gdb)
0x00000001012c59a0 in fclose () from /lib/x86_64-gnu/libc.so.0.3
=> 0x00000001012c59a0 <fclose+592>: 41 89 c4 mov
%eax,%r12d
(gdb) p/x $rax
$2 = 0xffffffff
---
[1] https://github.com/facebook/zstd/blob/v1.5.6/programs/fileio.c#L1878
File closure failures make the result variable to be set to 1 and
on line below
it is checked. Only if result is 0 (or the destination file
stdout) the file won't be
attempted to be removed
