This means that using --sendfile with compression silently disables compression. Worse, the CLI validation at client_cli.c:242 checks for this combination:
if(config->use_sendfile&&(config->use_chunk_serialization||config->use_compression)){fprintf(stderr,"Error: -f/--sendfile cannot be combined with -c (compression)\n");
But in the multithreaded path (client_send.c:145-161), the condition only checks !config->use_compression to decide the sendfile path, which is correct. However, the function signature is misleading since it advertises a compression parameter it cannot honor.
Fix: Either remove the parameter from the function signature, or implement compression support in the sendfile path using a temporary pipe.
Severity: low
In src/shared/file.c:436-468, the file_send_sendfile function accepts a compression_level parameter but explicitly ignores it:
```c
bool file_send_sendfile(File* file, int file_descriptor, bool use_metadata, int compression_level,
bool send_path) {
(void)compression_level; // silently ignored
```
This means that using --sendfile with compression silently disables compression. Worse, the CLI validation at client_cli.c:242 checks for this combination:
```c
if (config->use_sendfile && (config->use_chunk_serialization || config->use_compression)) {
fprintf(stderr, "Error: -f/--sendfile cannot be combined with -c (compression)\n");
```
But in the multithreaded path (client_send.c:145-161), the condition only checks `!config->use_compression` to decide the sendfile path, which is correct. However, the function signature is misleading since it advertises a compression parameter it cannot honor.
Fix: Either remove the parameter from the function signature, or implement compression support in the sendfile path using a temporary pipe.
Severity: low
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
In src/shared/file.c:436-468, the file_send_sendfile function accepts a compression_level parameter but explicitly ignores it:
This means that using --sendfile with compression silently disables compression. Worse, the CLI validation at client_cli.c:242 checks for this combination:
But in the multithreaded path (client_send.c:145-161), the condition only checks
!config->use_compressionto decide the sendfile path, which is correct. However, the function signature is misleading since it advertises a compression parameter it cannot honor.Fix: Either remove the parameter from the function signature, or implement compression support in the sendfile path using a temporary pipe.
Severity: low