1```
2This file tries to document file-related requests a client can make
3to the ADB server of an adbd daemon. See the OVERVIEW.TXT document
4to understand what's going on here. See the SERVICES.TXT to learn more
5about the other requests that are possible.
6
7SYNC SERVICES:
8
9
10Requesting the sync service ("sync:") using the protocol as described in
11SERVICES.TXT sets the connection in sync mode. This mode is a binary mode that
12differs from the regular adb protocol. The connection stays in sync mode until
13explicitly terminated (see below).
14
15After the initial "sync:" command is sent, the server must respond with either
16"OKAY" or "FAIL" as per the usual protocol.
17
18In sync mode both the server and the client will frequently use eight-byte
19packets to communicate. In this document these are called sync requests and sync
20responses. The first four bytes constitute an id that specifies the sync request.
21It is represented by four ASCII bytes in order to make them more human-readable
22when debugging. The last four bytes are a Little-Endian integer, with various
23uses. This number shall be called "length" below. In fact, all binary integers
24are Little-Endian in the sync mode. Sync mode is implicitly exited after each
25sync request, and normal adb communication follows as described in SERVICES.TXT.
26
27The following sync requests are accepted:
28LIST - List the files in a folder
29RECV - Retrieve a file from device
30SEND - Send a file to device
31STAT - Stat a file
32
33All of the sync requests above must be followed by "length": the number of
34bytes containing a utf-8 string with a remote filename.
35
36LIST:
37Lists files in the directory specified by the remote filename. The server will
38respond with zero or more directory entries or "dents".
39
40The directory entries will be returned in the following form
411. A four-byte sync response id "DENT"
422. A four-byte integer representing file mode.
433. A four-byte integer representing file size.
444. A four-byte integer representing last modified time.
455. A four-byte integer representing file name length.
466. length number of bytes containing an utf-8 string representing the file
47   name.
48
49When a sync response "DONE" is received the listing is done.
50
51SEND:
52The remote file name is split into two parts separated by the last
53comma (","). The first part is the actual path, while the second is a decimal
54encoded file mode containing the permissions of the file on device.
55
56Note that some file types will be deleted before the copying starts, and if
57the transfer fails. Some file types will not be deleted, which allows
58  adb push disk_image /some_block_device
59to work.
60
61After this the actual file is sent in chunks. Each chunk has the following
62format.
63A sync request with id "DATA" and length equal to the chunk size. After
64follows chunk size number of bytes. This is repeated until the file is
65transferred. Each chunk must not be larger than 64k.
66
67When the file is transferred a sync request "DONE" is sent, where length is set
68to the last modified time for the file. The server responds to this last
69request (but not to chunk requests) with an "OKAY" sync response (length can
70be ignored).
71
72
73RECV:
74Retrieves a file from device to a local file. The remote path is the path to
75the file that will be returned. Just as for the SEND sync request the file
76received is split up into chunks. The sync response id is "DATA" and length is
77the chunk size. After follows chunk size number of bytes. This is repeated
78until the file is transferred. Each chunk will not be larger than 64k.
79
80When the file is transferred a sync response "DONE" is retrieved where the
81length can be ignored.
82```