sparse file handling

[Björn JACKE]

Hi David,

I just had a look at sparse file handling and SEEK_HOLE/SEEK_DATA support in
Linux and I stumbled over some things here.

43e581188ab10 adds the FILE_SUPPORTS_SPARSE_FILES capability in case that
HAVE_FALLOC_FL_PUNCH_HOLE HAVE_LSEEK_HOLE_DATA are defined at compile time.
This is done unconditionally of the filesystem that is actually being used.

On the one hand we obviously do have sparse file support on any POSIX
filesystem and on the other hand the *filesystem* might not support SEEK_HOLE
or PUNCH_HOLE even though the kernel *generally* has support for that.

This is why I think the above generic condition of sparse support is not ideal.
Better might be to assume sparse capability generally and in sparse file
related functions react accordingly if lseek is giving back ENXIO like in cases
where SEEK_HOLE/SEEK_DATA is unsupported or if the tried fallocate call fails.

In the case sparse file capability is not set, SMB2 returns
NT_STATUS_NOT_SUPPORTED while SMB1 dummy-returns the whole range to work around
a bug, see 15531d9df1 and the comment on that in 3fdebc06465c.

smb2 should probably do the same as smb1 here to make MKS cp (and possible more
software) not break only on smb1 and work on smb1.

It would also be nice to get the pieces from fsctl_qar_seek_fill() from
source3/smbd/smb2_ioctl_filesys.c be more available so that this can be used in
source3/modules/vfs_default.c for FSCTL_QUERY_ALLOCATED_RANGES also.

Cheers
Björn