ouisync icon indicating copy to clipboard operation
ouisync copied to clipboard

File size reporting inside mounted repos fails with some utilities

Open Juul opened this issue 1 year ago • 3 comments

File sizes are reported correctly when using ls (Ubuntu 20.04, Bash 5.0.17):

~/ouisync/eq test 1$ ls -l
total 0
-r--r--r-- 1 root root 2077184 Dec 31  1969  1-MB-DOC.doc
-r--r--r-- 1 root root  179215 Dec 31  1969  74a468de-efb8-4a59-b3d5-228b9b4e8563.jpeg
-r--r--r-- 1 root root  621322 Dec 31  1969 'dandelion-445228_1920 (1).jpg'
-r--r--r-- 1 root root  621322 Dec 31  1969  dandelion-445228_1920.jpg
dr-xr-xr-x 1 root root     119 Dec 31  1969  F2
-r--r--r-- 1 root root  334832 Dec 31  1969  fantasy-2049567_1920.jpg
-r--r--r-- 1 root root  102912 Dec 31  1969  Free_Test_Data_100KB_DOC.doc
-r--r--r-- 1 root root 1320783 Dec 31  1969  sample_960x540.mp4

but are reported as zero when using e.g. du or ncdu:

~/ouisync/eq test 1$ du *
0	1-MB-DOC.doc
0	74a468de-efb8-4a59-b3d5-228b9b4e8563.jpeg
0	dandelion-445228_1920 (1).jpg
0	dandelion-445228_1920.jpg
0	F2
0	fantasy-2049567_1920.jpg
0	Free_Test_Data_100KB_DOC.doc
0	sample_960x540.mp4

ncdu:

--- /home/juul/ouisync/eq test 1 -----------------------------------------------
    0.0   B [          ]  1-MB-DOC.doc                                          
    0.0   B [          ]  sample_960x540.mp4
    0.0   B [          ]  dandelion-445228_1920.jpg
    0.0   B [          ]  dandelion-445228_1920 (1).jpg
    0.0   B [          ]  fantasy-2049567_1920.jpg
    0.0   B [          ]  74a468de-efb8-4a59-b3d5-228b9b4e8563.jpeg
    0.0   B [          ]  Free_Test_Data_100KB_DOC.doc
    0.0   B [          ] /F2

It doesn't matter of the repo was originally created locally or synced from another peer. Behavior is the same.

Juul avatar Jul 12 '24 03:07 Juul

https://redmine.equalit.ie/issues/31612

IvanaBlzvc avatar May 08 '25 09:05 IvanaBlzvc

Should be fixed by https://github.com/equalitie/ouisync/commit/7b7e4d80fe3b58982c67774cfd2883443ccd1450 (currently in the develop branch), though only for "standard" Linuxes where S_BLKSIZE is set to 512.

inetic avatar May 21 '25 10:05 inetic

For posterity:

du and likely other utilities as well expect blocks to be in units of S_BLKSIZE. Internally they multiply blocks by this value to get the "actual disc usage".

https://github.com/coreutils/coreutils/blob/8c9602e3a145e9596dc1a63c6ed67865814b6633/src/du.c#L572

  duinfo_set (&dui,
              (apparent_size
               ? (usable_st_size (sb) ? MAX (0, sb->st_size) : 0)
               : (uintmax_t) STP_NBLOCKS (sb) * ST_NBLOCKSIZE),   // <--- here
              (time_type == time_mtime ? get_stat_mtime (sb)
               : time_type == time_atime ? get_stat_atime (sb)
               : get_stat_ctime (sb)));

The STP_NBLOCKS(sb) returns the blocks variable that we set and ST_NBLOCKSIZE is defined in gnulib as

#  define ST_NBLOCKSIZE S_BLKSIZE

Unfortunately I was unable to find how we can get the S_BLKSIZE at runtime, so it is now hard-coded to 512.

inetic avatar May 21 '25 12:05 inetic