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```