Let me try to explain again.
TC as it is already does 99.9% of everything needed:
- emulates a file system when a container is mounted
- when used against a local-disk container - TC updates only the actually changed data block
The limitation comes from the way (I speak for windows here) the WebDAV Mini-Redirector (MRXDAV.SYS) is implemented, which operates only on the whole files.
If TC could bypass the MRXDAV.SYS to work with a storage directly - all the usual TC functionality would work automagically.
It would treat a WebDAV folder as a name of a container. Such a folder would keep gazillions of 512-byte files to represent (our usual) disk sectors. The names of those files would be the sequential numbers as if they are indeed disk sectors' numbers.
TC would create a container by creating a WebDAV folder and placing there as much 512-byte files as needed to comprise the user-requested size of a container. Then TC will fill all those file with random data - because of the container is being formatted to host a file system.
So the very first session will indeed consume a lot of traffic - the volume of a container created/formatted.
All the following sessions would have usable/realistic traffic - the volume of a file being put into a container, or volume of a changed part of a file accessed in a container.
The less we change in TC the better.
I aim at adding a layer between the encryption and disk I/O to redirect data to WebDAV (with minimal overhead like 512-byte files' name handling).
There is a library for that - the "neon" library.
I consulted with several WebDAV providers, they confirm the capability to not choke with those gazillions of 512-btye files I aim to keep with them.
And yes, there will be no compatibility with accessing such a folder with a browser!
If all the above is not a complete lunacy - an improvement could be further suggested: when creating a container (over WebDAV) - initially to not send files where no user or file system data is present.
So that the minimal traffic could be consumed even when formatting a container - just the container's header, the part of container where the FAT or NTFS data is located.
The volume of data being sent will linearly depend on the container actual usage. Like the "sparse files" in UNIX.