"files size" differs from "du -bs" results in quick view on folder

[unxed]

not sure if it can be considered bug or feature, but this behavour causes confusion at least

[unxed]

test folder included to reproduce this easily

test.zip

[elfmz]

far doesn't care about directory (own node) size reported by stat, that explain case when size in far less than in du
case when du's size less than far's more intresting. I guess du doesn't follow symlinks. Uncheck correspoding option in system settings and see if /home/unxed size will drop to <= du' report

[unxed]

unchecked "options"-"system settings"-"scan symbolic links"

got completely wrong result. at least, my "desktop" folder takes 55Gb and it is neither a symbolic link nor it has any symbolic links inside

[unxed]

far doesn't care about directory (own node) size reported by stat, that explain case when size in far less than in du

is this behavour can be considered expected? should be documented somehow at least, I guess.

[unxed]

re-checked with d81151c

10 bytes go to nowhere
you can reproduce this with your own "build" folder

[elfmz]

I know. its again related to symlinks

[unxed]

found the (possible) reason of home folder size difference.
it's a copy of "/bin" (full of symlinks) located inside /home/unxed/.local/share/Trash/files
(used it to test file copying progress time indicator)

so, to reprocude

1. mkdir ~/temp
2. copy /bin to ~/temp/bin with far
3. delete to recycle bin /temp with far
4. compare trash folder size calculated by far's quick view panel and "du -bs" results for that folder

btw, I still see some size difference after cleaning the recycle bin, investigating

[unxed]

far's quick view still shows ~/.wine taking 55G, but it really takes about 800M, and 55G is my desktop folder size. not sure if it matters. but then total size of ~ is calculated, .wine's 55G are not included.
with "scan symbolic links" option turned off .wine folder size is calculated correctly, but ~ size is messed.

[elfmz]

du -bs doesn't include size of objects pointed by symlinks, not sure whats wrong with your desktop dir, for me disabled symlinks gives almost same size of ~ as du -bs

[unxed]

reproduced.

the magic is, with "follow symlinks" option turned off, size of directories having symlinks pointing to them is not included in calculation

to reproduce:

1. disable "follow symlinks" option
2. mkdir ~/temp
3. mkdir ~/temp/a
4. copy something to ~/temp/a
5. ln -s ~/temp/a ~/temp/b
6. press ctrl+q on ~/temp
7. you WILL NOT see the size of the files you copied on step 4

sample included

temp.zip

UPD: seem to be fixed in 76ca1d0

[unxed]

still, even with "scan symbolic links", far's "files size" is slightly greater then du -bs
investigating

[unxed]

dosdevices.zip
(tar inside - to preserve symlinks)

[elfmz]

whats inside of dosdevices?

[unxed]

/home/unxed/.wine/dosdevices$ ls -la                                                       ↑
TIP: If you feel stuck - use Ctrl+Alt+C to terminate everything in this shell.
итого 8
drwxr-xr-x 2 unxed unxed 4096 окт 14 20:32 .
drwxr-xr-x 4 unxed unxed 4096 окт 22 23:26 ..
lrwxrwxrwx 1 unxed unxed   10 сен 30 14:22 c: -> ../drive_c
lrwxrwxrwx 1 unxed unxed    8 сен 30 14:50 d:: -> /dev/sdb
lrwxrwxrwx 1 unxed unxed    9 окт  1 08:23 e:: -> /dev/sdb1
lrwxrwxrwx 1 unxed unxed    8 окт 14 15:16 f:: -> /dev/sdc
lrwxrwxrwx 1 unxed unxed    9 окт 14 15:17 g:: -> /dev/sdc1
lrwxrwxrwx 1 unxed unxed    1 сен 30 14:22 z: -> /
/home/unxed/.wine/dosdevices$                                                              ↑

[elfmz]

also about scenario with lost size when disabled symlinks - was it checked before or after recent commit 76ca1d0 ?

[elfmz]

and what size shows far per each that file if enter dosdevices in ctrl+3 mode?

[unxed]

before. seems that 76ca1d0 fixed it.

[unxed]

[elfmz]

..and if select them

[elfmz]

I meant selected with ins to see their size in status area.. Anyway, check with recent changes

[unxed]

[elfmz]

..and now?

[unxed]

fixed with dosdevices, .wine and whole ~ in "no symbolic links scan" mode, YEAH :)
btw, does "scan symbolic links" option really need to be enabled by default?

[elfmz]

Don't know.. it was so in original version..
however there is small difference in profile's size between far2l and du.. Its because far creates temp file when building dir tree.. not sure why. and of course that file in ~/.far2l/tmp

[unxed]

guessed about temporary tree file. so waiting a little bit for du to show actual result.

59 411 034 356
for ~ in "no symbolic links scan" mode

59 411 212 209
for ~ in "scan symbolic links" mode

unxed@rs ~ $ sudo du -bs ~
59411034356 /home/unxed

• can it be considered correct? still not clear for me how "scan symbolic links" option works :)

[elfmz]

looks good..
Scan symbolic links mean that it will resolve symlinks found in directory and include its target into total size. This mean that if symlink points to file - the size of that file will be added to calculated total size. If symlink points ot directory - this directory will be added to recursive enumeration. There're also additional moments:

1. There is recursion guard, that checks if symlink target points to any scanned path or to some parent level (I added this) of scanned directory. In this case scan will not follow symlink even if symlink scan enabled.
2. There is also check for same files scan by device/inode identifiers (also my 'invention'). This excludes same files from being checked if there not recursive symlinks that points to same files. Also this prevents size of file that has more than one name (beside of symlinks there'is different beast called hardlinks!) to be added more than once.
   Bugs here where caused by:
3. In windows directory size always 0 and original far doesn't care about that field for directories. Not sure if that is correct, since nobody ever promised on Windows that reported for directories size is zero. Futhermore I'm not sure that its true for all possible filesystems including networking/3rd party encrypted containers etc.
4. symlink object has its own size
5. In windows symlink is always directory. So original code usually doesn't check if item is symlink if its not directory. In Linux its possible to make symlinks that point to files.

[unxed]

Thanks for detailed explanation!