(Illustration by Gaich Muramatsu)
(Illustration by Gaich Muramatsu)
For one, we throw away the stale entry before we start fetching the new one. When we disconnect during the fetch we suddenly have access to neither. I believe a getattr can be enough to lose the old data. There seems to be no way to detect the difference between stale data and stale metadata so we have the following 'fso states'
| data | |||
| metadata | none | stale | fresh |
| none | Y | N | N |
| stale | Y | Y | N |
| fresh | Y | N | Y |
When there is no metadata there is no Fso, so we definitely cannot have data. When the metadata is stale, the data could be fresh, but the callbacks don't carry that kind of information and we would revalidate the metadata before the data anyways. The obviously missing state that should be possible is the fresh/stale state.
However in this case we might have already given userspace the 'attributes' of the new object (size/mtime/etc.). So it will be confusing when the opened file is suddenly a different length. We also know that any writes to the file will lead to a conflict, as there already is a more recent version on the servers. So the easy way out was chosen, to discard an object whenever we get fresh metadata.