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

Previous Next

Full log

View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: Klaus-Jürgen Wolf <kjwolf <at> arcor.de>,  19072 <at> debbugs.gnu.org
Cc: werner.baumann <at> onlinehome.de
Subject: bug#19072: cp does not work with davfs2 (fuse) under GNU/Linux; coreutils-8.21
Date: Mon, 17 Nov 2014 01:23:38 +0000

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.