On the master we have a new receiveonly folder type, read the code,
I see the file added or modified for the receiveonly folder, When sending the index information, we will always set LocalFlags to 0, so consider the following scenario:
On machine A, add a send receive folder (empty directory) and share it to machine B.
On machine B, add the directory to receive only
Add some files to the directory of machine B.
dd if=/dev/urandom of=10m.bin count=10 bs=1M
Now on machine A, we can see that the global size is 10M and the local size is 0M. If there are more nodes like machine B, our global size will be very confusing.
I donāt understand why we want to send receiveonly file index to other nodes,
and force LocalFlags to 0, which interferes with global index.
If A (send receive) adds a file, and B (send only) modifies the file, we need to let C (send receive) know that the version of the file B has is fudged, and it should not go asking for it.
I guess it still has to send information about the files only existing on B, so that if a file with the same name is ever added on A, C knows that B has the file fudged.
Why is that counted towards the global size, I am not sure. I think it shouldnāt, as these files cannot be retrieved.
Thanks @AudriusButkevicius , now I know why want to send this kind of index.
For why is that counted towards the global size, because we forced LocalFlags to 0 when sending, the receiver does not know what happened. 0 is a regular state file.
Actually LocalFlags is always zero in global index, as the flags are local. The only thing that should matter is the invalid bit being set (which is not local), and invalid things should not be counted towards size in the global index.
Files on a device with a recvonly folder should count in both the local and global size, on that device, regardless of whether that file is locally changed or not. If Iāve missed counting them in the local size thatās a bug.
When announcing locally changed flags we should 1) set the invalid bit, 2) clear the version vector to zero. To other devices this will look like we have an infinitely old, broken version of the file and need to get in sync. This is by design. No other device should feel the desire to download our changed file, and it should not affect the calculation of which is the latest version of that file.
Yes, maybe. Perhaps the corner case is that when a file exists only in invalid variants it should not count toward then global state - although I think that will be no fun to implement. Otherwise this falls under the usual invalid-files-go-into-the-global-set case. I expect the effect is the same if I add a file, let it scan and announce, and then ignore it at the source.
Perhaps we should remove the global state as a concept in the UI, and just deal with local state plus needed itemsā¦ Itās not particularly āglobalā any more when every device can make five different types of exceptions from it.
Well, it should get re-announced with the invalid bit set when itās scanned as ignored, and look the same to other devices as above. (Assuming they donāt have the file already.)
Iām not saying this is a good look, but thatās itās a bit more general, affecting all files announced as invalid, afaik.
Ideally we might want to skip announcing files that were created on a recvonly side and hasnāt been modified by anyone else. But thereās no way to know that in general without adding more flags to the mix.
Actually, that could be solved without too much ugliness I thinkā¦
Before the local flags and metadata bucket stuff, we simply discarded invalid files in both local and global buckets. I donāt see why we should do that differently now, hence I think this is a regression.
No, youāre right, thatās a bug. The change correctly handles local files, which now get some sort of local flag and get accounted in another bucket which is then not counted in the global/local state. (Except for local-changed on recv-only folders.) But the handling of remote files with invalid bits changed and is wrong.