Double Commander not doing file compression in BTRFS partitions

[aug7744]

Hello. Thanks for reading my topic.
Here is Lubuntu 24.04.3 kernel 6.14.
BTRFS partition was mounted enabling compression in fstab ( compress-force=zlib:9 ).
Double Commander doing file operations in that BTRFS partition not does file compression for any file, but if using other file manager for example PCMANFM-QT and others softwares ( text editors ) is done file compression.
Using in terminal compsize show the compression used in directories.

I have done tests using Double commander in paths below, starting in root and apparmor disabled having the same results :

/home/username/doublecmd
/opt/doublecmd
/usr/bin using an symbolic link
/usr/local/bin

Perhaps Double Commander are using an internal own file operation code or for security the OS not are allowing file compression if using it.
Have any way to fix it ? OS have any configuration to allow that software to do any file operation without restrictions ?

Have a nice week.

 

[Trml]

I see there was an answer on github already why it does not do it. I reckon its focus on archives has to do with it.

To fix it later (after DC), you can run a defragmentation with compression option.

 

[aug7744]

Thanks for reply.
Double Commander creator didn't explain the problem.
I not want run defragmentation.
The correct is transparent compression.
Strange behavior not doing compression.

 

[piorunz]

Thanks for reply.
Double Commander creator didn't explain the problem.
I not want run defragmentation.
The correct is transparent compression.
Strange behavior not doing compression.

I have not read any github explanations, however, a solution for you seems to be clear:

Eliminate the problem then - don't use "Double Commander". Use something else that does not forcibly disable native Btrfs compression while copying files.

 

[Trml]

I agree, there is plenty double-plane filemanager implementations, should be easy to find similar (e.g. midnight commander).

Still, the github answer indeed did not reference compression itself, but another question asked by the OP - that the program uses standard kernel system calls. I was brief, because there was an answer by upstream and no reference made here. Not ideal, if you want to discuss a problem.

It could be a bug, e.g. it could be that the program reserves space (fallocate) before doing the copy. In this case, btrfs would not compress, even if compression is force-enabled.

But your test description in the bug is very vague, @aug7744. btrfs will decide if compressing makes sense. If you test with files that are not worth compressing (e.g. too small, or already compressed), it skips them. You should define the test cases very clearly and show the difference between using the program and a simple copy on the same examples. Otherwise the problem is not evident. If I were you, I'd add the test case output to the bug report - show how the compression is not applied using double commander and applied with standard copy on the same files. It's simple to use files in /usr/share/ as test cases