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