General doc grammar and typos
This commit is contained in:
@@ -10,7 +10,7 @@ are ignored.
|
||||
Example Scenario
|
||||
----------------
|
||||
|
||||
Assume two devices, "Alice" and "Bob", sharing a folder. Bob has set
|
||||
Assume two devices, "Alice" and "Bob", are sharing a folder. Bob has set
|
||||
``ignoreDelete``.
|
||||
|
||||
New and updated files are synchronized as usual between Alice and Bob. When
|
||||
|
||||
+1
-1
@@ -31,7 +31,7 @@ Prerequisites
|
||||
- Go **1.3** or higher
|
||||
- Git
|
||||
|
||||
If you're not a Go developer since before, the easiest way to get going
|
||||
If you're not already a Go developer, the easiest way to get going
|
||||
is to download the latest version of Go as instructed in
|
||||
http://golang.org/doc/install and ``export GOPATH=~``.
|
||||
|
||||
|
||||
+3
-3
@@ -44,21 +44,21 @@ facilities are something like this:
|
||||
- ``beacon`` sends and receives UDP broadcasts used by the local
|
||||
discovery system. Debugging here will show which interfaces and
|
||||
addresses are selected for broadcasts, etc.
|
||||
- ``discover`` sends and received local discovery packets. Debugging
|
||||
- ``discover`` sends and receives local discovery packets. Debugging
|
||||
here will output the parsed packets, nodes that get registered etc.
|
||||
- ``files`` keeps track of lists of files with metadata and figures out
|
||||
which is the newest version of each.
|
||||
- ``net`` shows connection attempts, incoming connections, and the low
|
||||
level error when connection attempts fail.
|
||||
- ``model`` is the largest chunk of the system; this is where pulling
|
||||
of out of date files happen, indexes sent and received, and incoming
|
||||
of out of date files happens, indexes are sent and received, and incoming
|
||||
requests for file chunks are logged.
|
||||
- ``scanner`` is the local filesystem scanner. Debugging here will
|
||||
output information about changed and unchanged files.
|
||||
- ``upnp`` is the upnp talker.
|
||||
- ``xdr`` is the low level protocol encoder. Debugging here will output
|
||||
all bytes sent/received over the sync connection. Very verbose.
|
||||
- ``all`` simply enabled debugging of all facilities.
|
||||
- ``all`` simply enables debugging of all facilities.
|
||||
|
||||
Enabling any of the facilities will also change the log format to
|
||||
include microsecond timestamps and file names plus line numbers. This
|
||||
|
||||
+1
-1
@@ -206,7 +206,7 @@ It could be mitigated in several ways:
|
||||
|
||||
- Announcements to the global announce server could be done using TLS,
|
||||
so the server calculates the device ID based on the certificate
|
||||
instead of trusting to the device to tell the truth.
|
||||
instead of trusting the device to tell the truth.
|
||||
|
||||
- The user could statically configure IP or host name for the devices.
|
||||
|
||||
|
||||
@@ -50,7 +50,7 @@ Runs Jenkins and does the core and Android builds, Ubuntu Linux.
|
||||
OSX and Windows Build Slaves
|
||||
----------------------------
|
||||
|
||||
Runs Jenkins build slaves and run builds and tests on the Mac and
|
||||
Runs Jenkins build slaves and runs builds and tests on the Mac and
|
||||
Windows operating systems. Hosted by :user:`Zillode`.
|
||||
|
||||
APT Server
|
||||
|
||||
+1
-1
@@ -106,7 +106,7 @@ lib/
|
||||
The local and global device discovery -- maps device IDs to IP and port tuples.
|
||||
|
||||
events/
|
||||
The event subsystem, handles emitting of and subscribing to events accross the other packages.
|
||||
The event subsystem, handles emitting of and subscribing to events across the other packages.
|
||||
|
||||
fnmatch/
|
||||
Matches strings to glob patterns, used by the ignore package.
|
||||
|
||||
+1
-1
@@ -63,7 +63,7 @@ protocol
|
||||
Milestone
|
||||
---------
|
||||
|
||||
There are milestones for major and sometimes minor versions. An issues
|
||||
There are milestones for major and sometimes minor versions. An issue
|
||||
being assigned to a milestone means it is a blocker - the release can't
|
||||
be made without the issue being closed. Issues not assigned to a
|
||||
milestone can be handled whenever.
|
||||
|
||||
@@ -44,7 +44,7 @@ Tag". Set the "Release title" to the same version as the tag, paste in
|
||||
the changelog from above, and publish the release.
|
||||
|
||||
On the signing server, logged in via ssh, run ``sign-upload-release``. This
|
||||
will create download the build artefacts from Jenkins, sign all the binaries,
|
||||
will download the build artefacts from Jenkins, sign all the binaries,
|
||||
create the sha1sum and sha256sum files, sign them with the release GPG key and
|
||||
upload the whole shebang to Github.
|
||||
|
||||
|
||||
+3
-3
@@ -19,14 +19,14 @@ device. Each time a change is made to the index information of an item (file
|
||||
or directory), that item is tagged with the current value of the local version
|
||||
counter, and the counter is increased.
|
||||
|
||||
Principal Operation
|
||||
-------------------
|
||||
Principal of Operation
|
||||
----------------------
|
||||
|
||||
Assume that the starting value of the counter is ``0``. The next change that
|
||||
happens will be assigned local version ``1``. Local scanning reveals the
|
||||
presence of three new files, ``foo``, ``bar`` and ``baz``. When ``foo`` is
|
||||
discovered, it's index entry gets assigned local version ``1`` and the counter
|
||||
is increased. Likewise ``bar`` gets ``2`` and ``foo`` gets ``3``.
|
||||
is increased. Likewise ``bar`` gets ``2`` and ``baz`` gets ``3``.
|
||||
|
||||
==== =============
|
||||
File Local Version
|
||||
|
||||
+2
-2
@@ -4,7 +4,7 @@ Selective Sync
|
||||
==============
|
||||
|
||||
This is for when you don't want to synchronize *all* files from the cluster
|
||||
onto your device, or you want only some directories of your to be synced
|
||||
onto your device, or you want only some directories of yours to be synced
|
||||
*to* the cluster. There are two mechanisms that support this usage; *Directory
|
||||
Selection* and *Excluded Files*.
|
||||
|
||||
@@ -50,7 +50,7 @@ changes will be downloaded from the cluster and local changes will not be
|
||||
tracked.
|
||||
|
||||
.. note:: When displaying the tree we must merge what we actually have on disk
|
||||
with what is in the global state.Or we will not be able to show new
|
||||
with what is in the global state, or we will not be able to show new
|
||||
directories to the user as we don't know about them...
|
||||
|
||||
|
||||
|
||||
@@ -75,6 +75,6 @@ Where block size is 128KB.
|
||||
|
||||
Files/folders appearing in the event data imply that the download has
|
||||
been started for that file/folder, where disappearing implies that the
|
||||
downloads has been finished or failed for that file/folder. There is
|
||||
downloads have been finished or failed for that file/folder. There is
|
||||
always a last event emitted with no data, which implies all downloads
|
||||
being finished/failed.
|
||||
have finished/failed.
|
||||
|
||||
@@ -22,7 +22,7 @@ Contact
|
||||
:ref:`project-presentation`.
|
||||
|
||||
* To report bugs or request features, please use the `issue tracker`_ Before you
|
||||
do so, make sure you are running the `latest version`_, and please do a
|
||||
do so, make sure you are running the `latest version`_, and please do a
|
||||
quick search to see if the issue has already been reported.
|
||||
|
||||
.. image:: issues.png
|
||||
|
||||
+2
-2
@@ -23,7 +23,7 @@ Stopped
|
||||
when the folder has experienced an error,
|
||||
|
||||
Scanning
|
||||
while the folder is looking for local changes,
|
||||
while Syncthing is looking in the folder for local changes,
|
||||
|
||||
Up to Date
|
||||
when the folder is in sync with the rest of the cluster,
|
||||
@@ -40,7 +40,7 @@ Local State
|
||||
shows how much data the folder actually contains right now. This can be more or less than the global state, if the folder is currently synchronizing with other devices.
|
||||
|
||||
Out of Sync
|
||||
shows how much data that needs to be synchronized from other devices. Note that this is the sum of all out of sync *files* - if you already have parts of such a file, or an older version of the file, less data than this will need to be transferred over the network.
|
||||
shows how much data needs to be synchronized from other devices. Note that this is the sum of all out of sync *files* - if you already have parts of such a file, or an older version of the file, less data than this will need to be transferred over the network.
|
||||
|
||||
Device View
|
||||
-----------
|
||||
|
||||
@@ -2,7 +2,7 @@ GET /rest/db/completion
|
||||
=======================
|
||||
|
||||
Returns the completion percentage (0 to 100) for a given device and
|
||||
folder.Takes ``device`` and ``folder`` parameters.
|
||||
folder. Takes ``device`` and ``folder`` parameters.
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
|
||||
@@ -11,11 +11,11 @@ reply; the only message type is Announcement.
|
||||
On multihomed hosts the announcement packets should be sent on each interface
|
||||
on which Syncthing will accept connections.
|
||||
|
||||
For IPv4, the Announcement packet is broadcasted either to the link-specific
|
||||
For IPv4, the Announcement packet is broadcast either to the link-specific
|
||||
broadcast address, or to the generic link-local broadcast address
|
||||
``255.255.255.255``, with destination port 21027.
|
||||
|
||||
For IPv6, the Announcement packet is multicasted to the transient link-local
|
||||
For IPv6, the Announcement packet is multicast to the transient link-local
|
||||
multicast address ``[ff12::8384]``, with destination port 21027.
|
||||
|
||||
It is recommended that local discovery Announcement packets be sent on a 30 to
|
||||
@@ -44,7 +44,7 @@ The Announcement packet has the following structure::
|
||||
\ Device Structure \
|
||||
/ /
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| Number of Extra |
|
||||
| Number of Extra Devices |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
/ /
|
||||
\ Zero or more Device Structures \
|
||||
@@ -136,7 +136,7 @@ bytes) of the device X.509 certificate, as explained in section *Device
|
||||
ID*.
|
||||
|
||||
For each ``Address`` and ``Relay`` the ``URL`` field contains the actual
|
||||
target address. For direction connections (the ``Address`` list) these will
|
||||
target address. Direct connections (the ``Address`` list) will
|
||||
typically have the ``tcp://`` scheme. Relay connections will typically use the
|
||||
``relay://`` scheme.
|
||||
|
||||
|
||||
+3
-3
@@ -43,7 +43,7 @@ directory the following files are located:
|
||||
Config File Format
|
||||
------------------
|
||||
|
||||
The following is shows the default configuration file:
|
||||
The following shows the default configuration file:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
@@ -123,7 +123,7 @@ id
|
||||
The folder ID, must be unique. (mandatory)
|
||||
|
||||
path
|
||||
The oath to the directory where the folder is stored on this
|
||||
The path to the directory where the folder is stored on this
|
||||
device; not sent to other devices. (mandatory)
|
||||
|
||||
ro
|
||||
@@ -339,7 +339,7 @@ globalAnnounceServer
|
||||
|
||||
globalAnnounceEnabled
|
||||
Whether to announce this device to the global announce (discovery) server,
|
||||
and also use it to look up other device.
|
||||
and also use it to look up other devices.
|
||||
|
||||
localAnnounceEnabled
|
||||
Whether to send announcements to the local LAN, also use such
|
||||
|
||||
+2
-2
@@ -142,7 +142,7 @@ safe from your (or our) mistakes.
|
||||
Why is there no iOS client?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Alternative implementation Syncthing (using the Syncthing protocol) are being
|
||||
An alternative implementation of Syncthing (using the Syncthing protocol) is being
|
||||
developed at this point in time to enable iOS support. Additionally, it seems
|
||||
that the next version of Go will support the darwin-arm architecture such that
|
||||
we can compile the mainstream code for the iOS platform.
|
||||
@@ -230,7 +230,7 @@ Where do Syncthing logs go to?
|
||||
|
||||
Syncthing logs to stdout by default. On Windows Syncthing by default also
|
||||
creates ``syncthing.log`` in Syncthing's home directory (check ``-help`` to see
|
||||
where that is). Command line option ``-logfile`` can be used to specify user-defined logfile.
|
||||
where that is). Command line option ``-logfile`` can be used to specify a user-defined logfile.
|
||||
|
||||
How do I upgrade Syncthing?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
Reverse Proxy Setup
|
||||
===================
|
||||
|
||||
A reverse proxy allow you to "pass" requests through your web server to another
|
||||
A reverse proxy allows you to "pass" requests through your web server to another
|
||||
site or program. The reverse proxy will make it look like Syncthing's GUI is a
|
||||
page within your existing site.
|
||||
|
||||
@@ -12,7 +12,7 @@ This is especially useful if:
|
||||
- You need to access the GUI on port 80 or 443 but you already host a website
|
||||
on the same device.
|
||||
- You want to share SSL certificates with an existing site.
|
||||
- You want to share authentification with an existing setup.
|
||||
- You want to share authentication with an existing setup.
|
||||
|
||||
Server Configuration
|
||||
--------------------
|
||||
|
||||
Reference in New Issue
Block a user