WebDAV folders internally have hundreds of copies of the same few files

[Ken Murchison]

On 11/15/18 1:48 AM, Anatoli wrote:
> Hi Ken,
>
> 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? unexpunge 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?


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.


> 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?
>
> 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)?


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?



> *From:* Ken Murchison
> *Sent:* Wednesday, November 14, 2018 10:54
> *To:* Info-cyrus
> *Subject:* Re: WebDAV folders internally have hundreds of copies of 
> the same few files
>
>
> On 11/13/18 10:15 PM, Anatoli wrote:
>> Hi,
>>
>> 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.
>>
>> 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.
>>
>> 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?
>>
>> Thanks,
>> Anatoli
>
>
> 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).
>
> -- 
> Ken Murchison
> Cyrus Development Team
> FastMail US LLC
>
> ----
> Cyrus Home Page:http://www.cyrusimap.org/
> List Archives/Info:http://lists.andrew.cmu.edu/pipermail/info-cyrus/
> To Unsubscribe:
> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
>
>
> ----
> Cyrus Home Page: http://www.cyrusimap.org/
> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
> To Unsubscribe:
> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20181115/74035ccb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: murch.vcf
Type: text/x-vcard
Size: 4 bytes
Desc: not available
URL: <http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20181115/74035ccb/attachment.vcf>