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.
