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 28SEND - Send a file to device 29RECV - Retreive a file from device 30 31Not yet documented: 32STAT - Stat a file 33ULNK - Unlink (remove) a file. (Not currently supported) 34 35For all of the sync request above the must be followed by length number of 36bytes containing an utf-8 string with a remote filename. 37 38LIST: 39Lists files in the directory specified by the remote filename. The server will 40respond with zero or more directory entries or "dents". 41 42The directory entries will be returned in the following form 431. A four-byte sync response id beeing "DENT" 442. A four-byte integer representing file mode. 453. A four-byte integer representing file size. 464. A four-byte integer representing last modified time. 475. A four-byte integer representing file name length. 486. length number of bytes containing an utf-8 string representing the file 49 name. 50 51When an sync response "DONE" is received the listing is done. 52 53SEND: 54The remote file name is split into two parts separated by the last 55comma (","). The first part is the actual path, while the second is a decimal 56encoded file mode containing the permissions of the file on device. 57 58Note that some file types will be deleted before the copying starts, and if 59the transfer fails. Some file types will not be deleted, which allows 60 adb push disk_image /some_block_device 61to work. 62 63After this the actual file is sent in chunks. Each chucks has the following 64format. 65A sync request with id "DATA" and length equal to the chunk size. After 66follows chunk size number of bytes. This is repeated until the file is 67transfered. Each chunk must not be larger than 64k. 68 69When the file is tranfered a sync request "DONE" is sent, where length is set 70to the last modified time for the file. The server responds to this last 71request (but not to chuck requests) with an "OKAY" sync response (length can 72be ignored). 73 74 75RECV: 76Retrieves a file from device to a local file. The remote path is the path to 77the file that will be returned. Just as for the SEND sync request the file 78received is split up into chunks. The sync response id is "DATA" and length is 79the chuck size. After follows chunk size number of bytes. This is repeated 80until the file is transfered. Each chuck will not be larger than 64k. 81 82When the file is transfered a sync resopnse "DONE" is retrieved where the 83length can be ignored. 84 85