Samba + exFAT : how to avoid pre-allocating when copying big files?

[Joseph]

Thank you Jeremy for your answer.
About your test, it seems the syntax might be 'seek' and not 'skip' (the
former skips bytes on output, the latter skips on input, i.e. /dev/null),
so I tried this:
sudo dd if=/dev/zero of=test2 bs=1k count=1 seek=1M   # seek 1 million of
1k blocks, i.e. 1 GB
Do you confirm it's what you were talking about?
And you're right, it takes a *long* time, meaning that the full file is
written, to only write 1k at the end...

---

I wonder why would the Windows Explorer client go to EOF first? Is there a
way to see (on the Samba server) the log of *all* operations sent by a
Samba client and received by the server, including file open, file seek,
file close, etc.? So that we could see if there is a seek to
position=2,000,000 when copying a 2GB file ?

More generally, do you have any idea about how we could avoid this annoying
behaviour?
Nowadays, many people use Samba + a Raspberry Pi or Linux in general to do
a NAS, and many people choose exFAT or NFTS for Windows compatibility
(let's say one day, they need to take the HDD out of the NAS, and plug it
to a Windows computer), since exFAT is well supported on both Windows and
Linux (the new non-fuse drivers seem good in terms of performance).

So it would be interesting to find a solution to address this exFAT
problem.

Would there be a trick, with maybe some clever use of a configuration Samba
option, to avoid this issue?
Or maybe could the Samba server send infos when connecting with the Windows
client saying that it should *not* seek to EOF to preallocate space?
For example would there be an old version that prevents this to happen
(protocol = SMB1 ?)

Fingers crossed that we can find a nice solution :)