If filter is set to show deleted files only, then the tree should show the size of the deleted files not 0 in all entries. This is needed to allow do find the directory where most data will be deleted and to get a quick overview if deletion is plausible. If the deleted size should be distinguished form copied size then e.g. show it with negative sign.
If filter is other than just deleted, the tree could also show deleted size, preferred with 2 numbers "[copy_size]-[delete_size]" (and use the correct binary IEC units KiB, MiB etc. and don't show the full word "Bytes"). In some cases showing the result of the difference as one number may also be convenient, or showing the sum as one number - but such types of display would need a configuration option, so that only users, which really want to see it in that way, get this display, and no "normal" user is confused.
FFS 6.7 beta
Show deleted size in tree if deleted files are shown only
- Posts: 4
- Joined: 1 Sep 2005
-
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
Showing negative numbers for deleted files won't work in general, since positive and negative numbers are added up for the next parent tree node. They would cancel each other out resulting in a new number with no useful meaning (= roughly a disk space delta).
Using different semantics based on how view filters are currently set is also no solution, since it will confuse users.
With these constraints I see two possible designs:
1. As it is right now: The numbers are a kind of sync preview showing how much data will be copied. (Reviewing the design I just noted an inconsistency for inactive items: they are still fully counted.)
2. The numbers could simply show how much data is available right now. If a file exists on both sides, it would pick the larger of the two sizes.
Which design is better depends on how users currently use or expect to use the overview panel: Do they want to know how much data will be copied at a folder level or how much data exists right now. I haven't really got any feedback about this in the last years, but it seems like 2 may be the better handling.
Using different semantics based on how view filters are currently set is also no solution, since it will confuse users.
With these constraints I see two possible designs:
1. As it is right now: The numbers are a kind of sync preview showing how much data will be copied. (Reviewing the design I just noted an inconsistency for inactive items: they are still fully counted.)
2. The numbers could simply show how much data is available right now. If a file exists on both sides, it would pick the larger of the two sizes.
Which design is better depends on how users currently use or expect to use the overview panel: Do they want to know how much data will be copied at a folder level or how much data exists right now. I haven't really got any feedback about this in the last years, but it seems like 2 may be the better handling.
- Posts: 85
- Joined: 28 Aug 2012
Actually, I like the way it is now. Except for the inconsistency that skipped items will not be counted by default, but will be counted when set manually to be skipped.
The reason I prefer option 1, is probably due to my 1-way syncs.
I can imagine 2-way sync users to prefer method 2, however.
Maybe the present handling could be kept for 1-way syncs only? With method 2, where a "file that exists on both sides, the size of the larger side will be shown" - the handling is not as intuitive for 1-way syncs as it is now.
The reason I prefer option 1, is probably due to my 1-way syncs.
I can imagine 2-way sync users to prefer method 2, however.
Maybe the present handling could be kept for 1-way syncs only? With method 2, where a "file that exists on both sides, the size of the larger side will be shown" - the handling is not as intuitive for 1-way syncs as it is now.
