Skip to content

iRODS replication fails when putting files via Davrods from the OS X built-in WevDAV client #12

@ilarik

Description

@ilarik

Hi,

I recently noticed that when putting files via Davrods to a replicated resource in iRODS 4.1.10 or iRODS 4.1.11, the replication fails and the new data object lands only in the first resource server it hits.

The really strange thing is that the failure only occurs when connecting via the OS X built-in WebDAV. Linux webdav clients my colleagues tested (GNOME Nautilus or davfs I suppose) worked perfectly. Also CyberDuck works.

For example:

-bash-4.2$ ils -l
/tempZone/home/rods:
  rods              0 replResc;rodsresc2Resource         5606 2017-12-12.16:23 & bash-history-orig.txt
  rods              1 replResc;rodsresc1Resource         5606 2017-12-12.16:23 & bash-history-orig.txt
  rods              0 replResc;rodsresc2Resource         4096 2017-12-12.16:18 & ._SC17 Final Program.pdf
  rods              1 replResc;rodsresc1Resource         4096 2017-12-12.16:18 & ._SC17 Final Program.pdf
  rods              0 replResc;rodsresc2Resource      5500794 2017-12-12.16:18 & SC17 Final Program.pdf
  rods              0 replResc;rodsresc2Resource      2593877 2017-12-12.16:16 & updates.img
-bash-4.2$ 

Here the file updates.img was uploaded via OS X native client, as well as SC17 Final Program.pdf (which had extended attributes). The file bash-history.orig.txt was uploaded from OS X via CyberDuck. To add insult to injury, iRODS replicated the xattr file but not the actual file, as you can see.

My personal guess is that the OS X WebDAV client does something stupid, which Davrods doesn't expect and causes a misbehavior in the iRODS protocol, which breaks replication.

Apache error log gave something possibly related:

[Tue Dec 12 16:18:41.282197 2017] [dav:error] [pid 12128] [client 192.168.56.1:61710] Unable to deliver content.  [500, #0]
[Tue Dec 12 16:18:41.282231 2017] [dav:error] [pid 12128] (32)Broken pipe: [client 192.168.56.1:61710] Could not write contents to filter.  [500, #0]

The iRODS endpoint server (in this case the iCAT) logs were clean as well as the rodsLog.* files on both of the resource servers.

The server environment was a cleanly built virtual cluster via irods-provisioner on CentOS 7 hosts, davrods-1.3.0 and iRODS 4.1.1.11.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions