bug#19072: cp does not work with davfs2 (fuse) under GNU/Linux; coreutils-8.21

[Pádraig Brady]

On 17/11/14 01:15, Pádraig Brady wrote:
> On 16/11/14 10:22, Klaus-Jürgen Wolf wrote:
>> With my cloud space provider, I have observed that copying to a davfs2
>> mounted cloud space does only work if using tar, e.g.
>>
>> tar -cf - sourcefile |tar -xf - -C clouddir
>>
>> Doing the same (copying) with cp or mv results in the error messages:
>>
>> cp: error writing ‘/home/kj/MyDrive/sourcefile’: Input/output error
>> cp: failed to extend ‘/home/kj/MyDrive/sourcefile’: Input/output error
>>
>> I suppose cp and mv use a file creation method not appropriate for this
>> kind of device. Either coreutils should detect the device and use a method
>> better suited, or coreutils should restrain to be plain and simple and make
>> use of a simple method working everywhere. (IMHO)
> 
> You seem to be getting an EIO error from ftruncate().
> That's used when creating sparse files which is automatically enabled
> when the source file is sparse.
> 
> Does passing --sparse=never avoid the issue for you?
> 
> BTW it's surprising that EIO is returned by davfs2 rather than ENOSYS or 
> ENOTSUP.
> Conceivably if davfs2 did return one of those error codes, then cp could fall 
> back
> to writing zeros in this unusual case (though it doesn't do that now).
> 
> For confirmation of the issue, could you provide the output of this command:
> 
>   for i in truncate seek; do
>     dd conv=notrunc count=0 seek=1 of=/home/kj/MyDrive/coreutils.test
>   done

I missed the "error writing" error message above,
which is given by EIO error from a plain old write().
That suggests a communications failure that cp is just reporting.
Is this a repeatable error?
Is any of the file written by cp?
Is the md5sum of the source and destination matching after tar writes the file?

thanks,
Pádraig.