文件操作 - NOTES.md
返回文件管理
返回主菜单
删除本文件
文件: /root/.local/share/Trash/files/roundcube/plugins/carddav/vendor/mstilkerich/carddavclient/NOTES.md
编辑文件内容
# Specifics of CardDAV server implementations ## Google Contacts Google's implementation of CardDAV is not compliant with the RFCs. The following issues have so far been encountered: ### Creating / update of cards - New cards should be inserted using a POST request (RFC 5995). The server will choose the URL and report it back via the Location header. - New cards inserted using PUT will be created, but not at the requested URI. Thus the URI in this case would be unknown, and hence this method should not be used. - Cards stored to the server are adapted by the server. The following has been observed so far: - When creating a card, the UID contained in the card is replaced by a server-assigned UID. - The PRODID property is discarded by the server - The server inserts a REV property ### Synchronization - When requesting a sync-collection report with an empty sync-token, the server rejects it as a bad request. - Using an empty sync-token is explicitly allowed by RFC 6578 for the initial sync, and subsequent sync when the sync-token was invalidated - It works to fallback to using PROPFIND to determine all cards in the addressbook - When attempting a sync-collection report with a sync-token previously returned by the server, Depth: 1 header is needed as otherwise the Google server apparently will only report on the collection itself, i. e. the sync result would look like there were no changes. According to RFC 6578, a Depth: 0 header is required and a bad request result should occur for any other value. [Issue](https://issuetracker.google.com/issues/160190530) - Google reports cards as deleted that have not been deleted between the last sync and the current one, but probably before that. [Issue](https://issuetracker.google.com/issues/160192237) <!-- vim: set ts=4 sw=4 expandtab fenc=utf8 ff=unix tw=120: -->
修改文件时间
将文件时间修改为当前时间的前一年
删除文件