search

leo-arch / clifm

The shell-like, command line terminal file manager: simple, fast, extensible, and lightweight as hell.
https://github.com/leo-arch/clifm/wiki
GNU General Public License v2.0
1.29k stars 41 forks source link

file sizes not good anymore #251

Closed muellerto closed 10 months ago

muellerto commented 10 months ago

Describe the bug The file sizes (I use exact bytes) in the long view are not good anymore. It seems that they are always somehow rounded up to blocks of 1024 bytes.

To Reproduce Steps to reproduce the behavior:

  1. configure to show exact bytes, my PropFields setting is fpmSx
  2. just look at the file sizes in a list of files - all wrong
  3. press p or pp - also wrong

I checked also s in PropFields, this is also not good anymore.

Expected behavior Earlier versions of clifm showed exact file sizes correctly.

Screenshots The following picture shows clifm and ls -l with the same directory:

2

All file sizes differ. ls -l shows the correct file sizes.

Desktop:

leo-arch commented 10 months ago

Looks like it's displaying actual disk usage (and your OS is reporting blocks of 1024k) instead of apparent sizes. What's the value of ApparentSize in your config file? By default it's set to true.

muellerto commented 10 months ago

ApparentSize was false in my case.

When I set it true the file sizes get much better (I would say they are correct).

ApparentSize was always false on this machine. I didn't change it as far as I can remember. But the file size display changed recently. So either clifm or the OS or my MinGW du has changed it's behavior. But who?

My MinGW du supports the parameter --apperent-size. When I type du --apparent-size --bytes *.* I get the exact sizes I want to have. But I get exactly the same correct results when I type du --bytes *.*. When I type du *.* I get kilo bytes, OK, but even these numbers are different from what clifm shows. In my picture above clifm shows both MainPage.html files as 8192 bytes while du says one file has 8 kB, the other one has 6 kB. Mysterious.

I let ApparentSize be true as long as I don't see problems with that. Thanks for the lead on that.

leo-arch commented 10 months ago

Glad it's working again. Just a few remarks:

  1. ApparentSize has always been set to true by default. There has been no change in this regard as far as I can remember.
  2. Clifm will never modify the user's config file, even if some option is set to a wrong value.
  3. du(1) is not involved here at all: file sizes are computed using the values returned by the stat(2) syscall (du is only used to get directories size recursively, for example, when you run pp on a directory).

Please keep me informed about any unusual or unexpected behavior.

EDIT: Nope, it seems I was wrong: ApparentSize was originally set to false. However, the important thing is whether sizes are displayed correctly or not, i.e. respecting the user's settings.

As far as I can tell, the sizes shown in your screenshot are correct (file disk usage in blocks of 1024 bytes, which is Cygwin default block size (see the S_BLKSIZE macro in sys/stat.h)). Also, setting ApparentSize to true produced the right change: actual file sizes instead of disk usage. In any case, if these values were different before, without altering the value of ApparentSize, it was a clifm bug that has been fixed.

EDIT2: Made a few tests on my Windows box. ApparentSize was actually set to false; nonetheless, file sizes were as expected. Tried with both the latest version and 1.13.

muellerto commented 10 months ago
  1. Yes, may be. Probably it was me who did set ApparentSize false in the very beginning since it's comment was always "Linux only". And so it was at least for a year or so. I swear I didn't change it in the last weeks but the file size display changed recently. That was the reason for this issue.
  2. Yes, sure, I didn't claim that.
  3. du is mentioned in the comment of the ApparentSize option in my not very actual clifmrc. (I should finally get an actual one ...) I don't know how or if du is involved in anything at all but for the case it is I checked it's behavior.

After all the behavior seems to be correct in both cases, ApparentSize=true and ApparentSize=false. It was probably not right before when it showed indeed exact bytes for a long time with ApparentSize=false which has been the case on my machine until today. I always wanted exact bytes (we discussed this here and you implemented this feature) and suddenly not longer than a week ago I didn't have them anymore.