<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body smarttemplateinserted="true">
    <div id="smartTemplate4-quoteHeader">
      <div style="font-size:10.0pt;font-family:Verdana,Arial">Ken,<br>
        <br>
        > If you login as an admin, you should be able to SELECT the
        mailbox and use normal IMAP commands.  Alternatively, if you add
        "+DAV" to a regular userid, this will also allow SELECTing of
        DAV collection mailboxes.<br>
        <br>
        When I do <font face="Courier New">imtest -a mailadmin</font>
        and then issue <font face="Courier New">a002 select
          #drive/folder</font>, I get:<br>
        <font face="Courier New"><br>
          a002 NO Invalid mailbox type<br>
        </font><br>
        When I do <font face="Courier New">imtest -a mailadmin+DAV</font>,
        I get (<font face="Courier New">XX</font> replaces the real auth
        value):<br>
        <br>
        <font face="Courier New">C: A01 AUTHENTICATE PLAIN
          XXXXXXXXXXXXXXXXXXX<br>
          S: A01 NO authentication failure<br>
          Authentication failed. generic failure<br>
        </font><br>
        I've also tried these combinations with the same result:
        <a class="moz-txt-link-rfc2396E" href="mailto:user@domain.tld+DAV">"user@domain.tld+DAV"</a> and <a class="moz-txt-link-rfc2396E" href="mailto:user+DAV@domain.tld">"user+DAV@domain.tld"</a>. Am I doing it
        wrong?<br>
        <br>
        Independently of this, is there a way to obtain the details
        about the flags for each message in a folder directly from the
        db files? My idea is to rsync the Cyrus store where the WebDAV
        is located to some other folder (probably on another server),
        purge there the files marked as deleted and backup the remaining
        files, all this without altering the Cyrus store. Is it
        possible?<br>
        <br>
        <br>
        > If the append of the resource into the mailbox, or updating
        the DAV db entry fails, the operation should be reverted, with
        partial saving done.  Which version of Cyrus are you using?<br>
        <br>
        Currently it is 3.0.5, but I can upgrade if there were any
        related changes in the later versions. What I was observing is
        that if a PC (LibreOffice Calc on Ubuntu 16.04, the folder
        mounted with davfs2) crashes in the middle of saving a file on
        the server, the result was a damaged file: some 400 bytes
        instead of 3-4Mb of a real file.<br>
        <br>
        I was thinking that maybe when the TCP stream hangs in the
        middle, Cyrus would interpret it as an end of data and write a
        file, but I've just tried to make some tests killing <font
          face="Courier New">mount.davfs2</font> process and/or blocking
        the stream with iptables in the middle of file transmission and
        Cyrus responded correctly. For killing <font face="Courier New">mount.davfs2</font>
        it showed in the corresponding log file the bytestream followed
        by:<br>
        <br>
        <font face="Courier New">HTTP/1.1 400 Bad Request<br>
          <br>
          Unable to read body data<br>
        </font><br>
        And for blocking the stream with iptables it was showing the
        bytestream ending where the transmission stopped, without the
        400 Bad Request, but in both cases the original file was not
        modified by the partial upload. So it appears the problem is
        elsewhere.<br>
        <br>
        <br>
        Regards,<br>
        Anatoli<br>
        <br>
      </div>
      <div style="border:none;border-top:solid #B5C4DF
        1.0pt;padding:3.0pt 0cm 0cm
0cm;font-size:10.0pt;font-family:"Tahoma","sans-serif""><b>From:</b>
        Ken Murchison<br>
        <b>Sent:</b> Thursday, November 15, 2018 14:09<br>
        <b>To:</b> Info-cyrus<br>
        <b>Subject:</b> Re: WebDAV folders internally have hundreds of
        copies of the same few files<br>
      </div>
      <br>
    </div>
    <span type="cite"
      cite="mid:dd800c9d-7fb9-d453-5cfb-82bcd617602a@fastmail.com"
      style="display: block; word-break: break-all; margin: 7px 0 0 0;
      padding: 0; line-height:0"></span>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 11/15/18 1:48 AM, Anatoli wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:377b8a00-5c8d-3c86-342a-61f4526b0015@anatoli.ws">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <div id="smartTemplate4-quoteHeader">
        <div style="font-size:10.0pt;font-family:Verdana,Arial">Hi Ken,<br>
          <br>
          Thanks a lot for the clarification, everything makes sense
          now. How can I list the files marked for deletion and those
          that are not marked? <font face="Courier New">unexpunge</font>
          can provide the list of files marked for deletion, is there
          any better way to list them, directly reading the DB? How to
          list those that are not marked?<br>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>If you login as an admin, you should be able to SELECT the
      mailbox and use normal IMAP commands.  Alternatively, if you add
      "+DAV" to a regular userid, this will also allow SELECTing of DAV
      collection mailboxes.</p>
    <p><br>
    </p>
    <blockquote type="cite"
      cite="mid:377b8a00-5c8d-3c86-342a-61f4526b0015@anatoli.ws">
      <div id="smartTemplate4-quoteHeader">
        <div style="font-size:10.0pt;font-family:Verdana,Arial"> One
          more question, related: we got a client who's PC was crashing
          exactly during the modify operation (some issue with the PC
          hardware triggered by Excel save operation, probably a RAM
          spike touching some bad blocks). As a result, the file in
          Cyrus was becoming damaged, i.e. partially saved. Is it
          expected?<br>
          <br>
          Shouldn't Cyrus update the db with the pointer to the new file
          (a new message in the store) only if the operation completes
          successfully (e.g. the WebDAV messages exchange completes and
          the connection is closed at the right time or something
          similar)?<br>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>If the append of the resource into the mailbox, or updating the
      DAV db entry fails, the operation should be reverted, with partial
      saving done.  Which version of Cyrus are you using?</p>
    <p><br>
    </p>
    <br>
    <blockquote type="cite"
      cite="mid:377b8a00-5c8d-3c86-342a-61f4526b0015@anatoli.ws">
      <div id="smartTemplate4-quoteHeader">
        <div style="border:none;border-top:solid #B5C4DF&#xA;&#xA;
          1.0pt;padding:3.0pt
0cm&#xA;0cm&#xA;0cm;font-size:10.0pt;font-family:"Tahoma","sans-serif""><b>From:</b>
          Ken Murchison<br>
          <b>Sent:</b> Wednesday, November 14, 2018 10:54<br>
          <b>To:</b> Info-cyrus<br>
          <b>Subject:</b> Re: WebDAV folders internally have hundreds of
          copies of the same few files<br>
        </div>
        <br>
      </div>
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <p><br>
      </p>
      <div class="moz-cite-prefix">On 11/13/18 10:15 PM, Anatoli wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:024e49fa-74d2-613f-1d5a-36497dffae04@anatoli.ws">
        <meta http-equiv="content-type" content="text/html;
          charset=UTF-8">
        <div id="smartTemplate4-template">
          <div style="font-size:10.0pt;font-family:Verdana,Arial"> Hi,<br>
            <br>
            I'm not sure this is due to some configuration option, bug
            or feature, but I'm observing some folders on Cyrus HTTP
            WebDAV server having hundreds (995 at this moment to be
            precise) internal files in the format "NNN." that correspond
            to the same file but different versions in time.<br>
            <br>
            There are 2-3 files (xls) in the folder that are edited
            constantly during the day and it looks like each save
            operation creates a new file. The files are of some 3-5Mb
            each. In the explorer/web view there are only a couple of
            files with a total size of 17.5Mb, but the reported disk
            usage for the folder is of 1.6Gb.<br>
            <br>
            Could someone please shed some light on what's going on and
            how to make each file visible to the users to be stored in
            only one internal file?<br>
            <br>
            Thanks,<br>
            Anatoli</div>
        </div>
      </blockquote>
      <p><br>
      </p>
      <p>Because *DAV is layered on top of an IMAP store, we have to
        abide by IMAP semantics in which messages (in this case DAV
        resources) are immutable.  Therefore, we can NOT overwrite an
        existing message in the mailbox.  Each change MUST result in a
        new message.  However, the server does mark the previous
        version(s) as deleted and expunged, which means that they will
        eventually be removed by cyr_expire.  If you aren't running
        cyr_expire, you should consider adding an event to cyrus.conf to
        remove expunged messages (see -X option).<br>
      </p>
      <pre class="moz-signature" cols="72">-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">----
Cyrus Home Page: <a class="moz-txt-link-freetext" href="http://www.cyrusimap.org/" moz-do-not-send="true">http://www.cyrusimap.org/</a>
List Archives/Info: <a class="moz-txt-link-freetext" href="http://lists.andrew.cmu.edu/pipermail/info-cyrus/" moz-do-not-send="true">http://lists.andrew.cmu.edu/pipermail/info-cyrus/</a>
To Unsubscribe:
<a class="moz-txt-link-freetext" href="https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus" moz-do-not-send="true">https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus</a></pre>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">----
Cyrus Home Page: <a class="moz-txt-link-freetext" href="http://www.cyrusimap.org/" moz-do-not-send="true">http://www.cyrusimap.org/</a>
List Archives/Info: <a class="moz-txt-link-freetext" href="http://lists.andrew.cmu.edu/pipermail/info-cyrus/" moz-do-not-send="true">http://lists.andrew.cmu.edu/pipermail/info-cyrus/</a>
To Unsubscribe:
<a class="moz-txt-link-freetext" href="https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus" moz-do-not-send="true">https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus</a></pre>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC</pre>
    <br>
    <fieldset class="mimeAttachmentHeader"></fieldset>
    <pre class="moz-quote-pre" wrap="">----
Cyrus Home Page: <a class="moz-txt-link-freetext" href="http://www.cyrusimap.org/">http://www.cyrusimap.org/</a>
List Archives/Info: <a class="moz-txt-link-freetext" href="http://lists.andrew.cmu.edu/pipermail/info-cyrus/">http://lists.andrew.cmu.edu/pipermail/info-cyrus/</a>
To Unsubscribe:
<a class="moz-txt-link-freetext" href="https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus">https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus</a></pre>
    <br>
  </body>
</html>