You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/architecture.rst
+18-28Lines changed: 18 additions & 28 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,7 +21,7 @@ result, the Nextcloud Client runs on Linux, Windows, and MacOS.
21
21
The Synchronization Process
22
22
---------------------------
23
23
24
-
The process of synchronization keeps files in two separate repositories the
24
+
The process of synchronization keeps files in two separate repositories the
25
25
same. When synchronized:
26
26
27
27
- If a file is added to one repository it is copied to the other synchronized repository.
@@ -93,7 +93,7 @@ traverses the file tree and compares the modification time of each file with an
93
93
expected value stored in its database. If the value is not the same, the client
94
94
determines that the file has been modified in the local repository.
95
95
96
-
.. note:: On the local side, the modification time is a good attribute to use for
96
+
.. note:: On the local side, the modification time is a good attribute to use for
97
97
detecting changes, because
98
98
the value does not depend on time shifts and such.
99
99
@@ -122,7 +122,7 @@ Conflict files are always created on the client and never on the server.
122
122
123
123
In ownCloud 10.0 we implemented a checksum feature which checks the file integrity on upload and download by computing a checksum after the file transfer finishes.
124
124
The client queries the server capabilities after login to decide which checksum algorithm to use.
125
-
Currently, SHA1 is hard-coded in the official server release and can't be changed by the end-user.
125
+
Currently, SHA1 is hard-coded in the official server release and can't be changed by the end-user.
126
126
Note that the server additionally also supports MD5 and Adler-32, but the desktop client will always use the checksum algorithm announced in the capabilities:
127
127
128
128
::
@@ -202,14 +202,14 @@ Conflict files are always created on the client and never on the server.
202
202
Upload
203
203
~~~~~~
204
204
205
-
A checksum is calculated with the previously negotiated algorithm by the client and sent along with the file in an HTTP Header.
205
+
A checksum is calculated with the previously negotiated algorithm by the client and sent along with the file in an HTTP Header.
206
206
```OC-Checksum: [algorithm]:[checksum]```
207
207
208
208
.. image:: ./images/checksums/client-activity.png
209
209
210
-
During file upload, the server computes SHA1, MD5, and Adler-32 checksums and compares one of them to the checksum supplied by the client.
210
+
During file upload, the server computes SHA1, MD5, and Adler-32 checksums and compares one of them to the checksum supplied by the client.
211
211
212
-
On mismatch, the server returns HTTP Status code 400 (Bad Request) thus signaling the client that the upload failed.
212
+
On mismatch, the server returns HTTP Status code 400 (Bad Request) thus signaling the client that the upload failed.
213
213
The server then discards the upload, and the client blacklists the file:
@@ -223,29 +223,29 @@ Conflict files are always created on the client and never on the server.
223
223
client.</s:message>
224
224
</d:error>
225
225
226
-
The client retries the upload using exponential back-off.
226
+
The client retries the upload using exponential back-off.
227
227
On success (matching checksum) the computed checksums are stored by the server in ``oc_filecache`` alongside the file.
228
228
229
229
Chunked Upload
230
230
~~~~~~~~~~~~~~
231
231
232
-
Mostly same as above.
233
-
The checksum of the full file is sent with every chunk of the file.
232
+
Mostly same as above.
233
+
The checksum of the full file is sent with every chunk of the file.
234
234
But the server only compares the checksum after receiving the checksum sent with the last chunk.
235
235
236
236
Download
237
237
~~~~~~~~
238
238
239
239
The server sends the checksum in an HTTP header with the file. (same format as above).
240
-
If no checksum is found in ``oc_filecache`` (freshly mounted external storage) it is computed and stored in ``oc_filecache`` on the first download.
241
-
The checksum is then provided on all subsequent downloads but not on the first.
240
+
If no checksum is found in ``oc_filecache`` (freshly mounted external storage) it is computed and stored in ``oc_filecache`` on the first download.
241
+
The checksum is then provided on all subsequent downloads but not on the first.
242
242
243
243
.. _ignored-files-label:
244
244
245
245
Ignored Files
246
246
-------------
247
247
248
-
The Nextcloud Client supports the ability to exclude or ignore certain files from the synchronization process.
248
+
The Nextcloud Client supports the ability to exclude or ignore certain files from the synchronization process.
249
249
Some system wide file patterns that are used to exclude or ignore files are included with the client by default and the Nextcloud Client provides the ability to add custom patterns.
250
250
251
251
By default, the Nextcloud Client ignores the following files:
@@ -262,18 +262,18 @@ By default, the Nextcloud Client ignores the following files:
262
262
If a pattern selected using a checkbox in the `ignoredFilesEditor-label` (or if
263
263
a line in the exclude file starts with the character ``]`` directly followed by
264
264
the file pattern), files matching the pattern are considered *fleeting meta
265
-
data*.
265
+
data*.
266
266
267
267
These files are ignored and *removed* by the client if found in the
268
-
synchronized folder.
268
+
synchronized folder.
269
269
This is suitable for meta files created by some applications that have no sustainable meaning.
270
270
271
-
If a pattern ends with the forward slash (``/``) character, only directories are matched.
271
+
If a pattern ends with the forward slash (``/``) character, only directories are matched.
272
272
The pattern is only applied for directory components of filenames selected using the checkbox.
273
273
274
274
To match filenames against the exclude patterns, the UNIX standard C library
275
-
function ``fnmatch`` is used.
276
-
This process checks the filename against the specified pattern using standard shell wildcard pattern matching.
275
+
function ``fnmatch`` is used.
276
+
This process checks the filename against the specified pattern using standard shell wildcard pattern matching.
277
277
For more information, please refer to `The opengroup website
@@ -440,13 +440,3 @@ Files that must be removed from the local storage only, need to be dehydrated vi
440
440
441
441
.. note::
442
442
* End-to-end Encryption works with Virtual Files (VFS) but only on a per-folder level. Folders with E2EE can be made available offline in their entirety, but the individual files in them can not be retrieved on demand. This is mainly due to two technical reasons. First, the Windows VFS API is not designed for handling encrypted files. Second, while the VFS is designed to deal mostly with large files, E2EE is mostly recommended for use with small files as encrypting and decrypting large files puts large demands on the computer infrastructure.
443
-
444
-
445
-
User Status
446
-
-----------
447
-
448
-
Starting from 3.2.0, user status is displayed in the Nextcloud desktop client's tray window. The icon and a text message are displayed as long as those are set in the user's account menu in the Web UI (server's website). At the moment, setting the status from the desktop client is not available.
449
-
The status is updated almost immediately after it is set in the Web UI. Default user status is always "Online" if no other status is available from the server-side.
0 commit comments