2009-05-15 13:07:06 +00:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2009 The Android Open Source Project
|
|
|
|
*
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
* You may obtain a copy of the License at
|
|
|
|
*
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
*
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
* limitations under the License.
|
|
|
|
*/
|
|
|
|
|
2009-05-05 18:50:51 +00:00
|
|
|
#define LOG_TAG "file_backup_helper"
|
|
|
|
|
2009-06-04 20:53:57 +00:00
|
|
|
#include <utils/BackupHelpers.h>
|
2009-05-05 18:50:51 +00:00
|
|
|
|
|
|
|
#include <utils/KeyedVector.h>
|
|
|
|
#include <utils/ByteOrder.h>
|
|
|
|
#include <utils/String8.h>
|
|
|
|
|
|
|
|
#include <errno.h>
|
|
|
|
#include <sys/types.h>
|
|
|
|
#include <sys/uio.h>
|
|
|
|
#include <sys/stat.h>
|
2009-05-22 20:41:38 +00:00
|
|
|
#include <sys/time.h> // for utimes
|
2009-05-05 18:50:51 +00:00
|
|
|
#include <stdio.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <unistd.h>
|
2009-05-06 16:55:46 +00:00
|
|
|
#include <utime.h>
|
2009-05-05 18:50:51 +00:00
|
|
|
#include <fcntl.h>
|
|
|
|
#include <zlib.h>
|
|
|
|
|
|
|
|
#include <cutils/log.h>
|
|
|
|
|
2009-05-15 13:07:06 +00:00
|
|
|
namespace android {
|
2009-05-05 18:50:51 +00:00
|
|
|
|
|
|
|
#define MAGIC0 0x70616e53 // Snap
|
|
|
|
#define MAGIC1 0x656c6946 // File
|
|
|
|
|
2009-06-24 00:35:11 +00:00
|
|
|
/*
|
|
|
|
* File entity data format (v1):
|
|
|
|
*
|
|
|
|
* - 4-byte version number of the metadata, little endian (0x00000001 for v1)
|
|
|
|
* - 12 bytes of metadata
|
|
|
|
* - the file data itself
|
|
|
|
*
|
|
|
|
* i.e. a 16-byte metadata header followed by the raw file data. If the
|
|
|
|
* restore code does not recognize the metadata version, it can still
|
|
|
|
* interpret the file data itself correctly.
|
|
|
|
*
|
|
|
|
* file_metadata_v1:
|
|
|
|
*
|
|
|
|
* - 4 byte version number === 0x00000001 (little endian)
|
|
|
|
* - 4-byte access mode (little-endian)
|
|
|
|
* - undefined (8 bytes)
|
|
|
|
*/
|
|
|
|
|
|
|
|
struct file_metadata_v1 {
|
|
|
|
int version;
|
|
|
|
int mode;
|
|
|
|
int undefined_1;
|
|
|
|
int undefined_2;
|
|
|
|
};
|
|
|
|
|
|
|
|
const static int CURRENT_METADATA_VERSION = 1;
|
|
|
|
|
2009-06-26 21:19:11 +00:00
|
|
|
#if 1
|
|
|
|
#define LOGP(f, x...)
|
|
|
|
#else
|
|
|
|
#if TEST_BACKUP_HELPERS
|
2009-06-11 00:07:15 +00:00
|
|
|
#define LOGP(f, x...) printf(f "\n", x)
|
2009-05-15 13:07:06 +00:00
|
|
|
#else
|
2011-12-20 16:23:08 +00:00
|
|
|
#define LOGP(x...) ALOGD(x)
|
2009-05-15 13:07:06 +00:00
|
|
|
#endif
|
2009-06-26 21:19:11 +00:00
|
|
|
#endif
|
2009-05-13 22:57:29 +00:00
|
|
|
|
2009-05-05 18:50:51 +00:00
|
|
|
const static int ROUND_UP[4] = { 0, 3, 2, 1 };
|
|
|
|
|
|
|
|
static inline int
|
|
|
|
round_up(int n)
|
|
|
|
{
|
|
|
|
return n + ROUND_UP[n % 4];
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
read_snapshot_file(int fd, KeyedVector<String8,FileState>* snapshot)
|
|
|
|
{
|
|
|
|
int bytesRead = 0;
|
|
|
|
int amt;
|
|
|
|
SnapshotHeader header;
|
|
|
|
|
|
|
|
amt = read(fd, &header, sizeof(header));
|
|
|
|
if (amt != sizeof(header)) {
|
|
|
|
return errno;
|
|
|
|
}
|
|
|
|
bytesRead += amt;
|
|
|
|
|
|
|
|
if (header.magic0 != MAGIC0 || header.magic1 != MAGIC1) {
|
2012-01-05 23:22:43 +00:00
|
|
|
ALOGW("read_snapshot_file header.magic0=0x%08x magic1=0x%08x", header.magic0, header.magic1);
|
2009-05-05 18:50:51 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (int i=0; i<header.fileCount; i++) {
|
|
|
|
FileState file;
|
|
|
|
char filenameBuf[128];
|
|
|
|
|
2009-06-11 00:07:15 +00:00
|
|
|
amt = read(fd, &file, sizeof(FileState));
|
|
|
|
if (amt != sizeof(FileState)) {
|
2012-01-05 23:22:43 +00:00
|
|
|
ALOGW("read_snapshot_file FileState truncated/error with read at %d bytes\n", bytesRead);
|
2009-05-05 18:50:51 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
bytesRead += amt;
|
|
|
|
|
|
|
|
// filename is not NULL terminated, but it is padded
|
|
|
|
int nameBufSize = round_up(file.nameLen);
|
|
|
|
char* filename = nameBufSize <= (int)sizeof(filenameBuf)
|
|
|
|
? filenameBuf
|
|
|
|
: (char*)malloc(nameBufSize);
|
|
|
|
amt = read(fd, filename, nameBufSize);
|
|
|
|
if (amt == nameBufSize) {
|
|
|
|
snapshot->add(String8(filename, file.nameLen), file);
|
|
|
|
}
|
|
|
|
bytesRead += amt;
|
|
|
|
if (filename != filenameBuf) {
|
|
|
|
free(filename);
|
|
|
|
}
|
|
|
|
if (amt != nameBufSize) {
|
2012-01-05 23:22:43 +00:00
|
|
|
ALOGW("read_snapshot_file filename truncated/error with read at %d bytes\n", bytesRead);
|
2009-05-05 18:50:51 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (header.totalSize != bytesRead) {
|
2012-01-05 23:22:43 +00:00
|
|
|
ALOGW("read_snapshot_file length mismatch: header.totalSize=%d bytesRead=%d\n",
|
2009-05-05 18:50:51 +00:00
|
|
|
header.totalSize, bytesRead);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2009-06-11 00:07:15 +00:00
|
|
|
write_snapshot_file(int fd, const KeyedVector<String8,FileRec>& snapshot)
|
2009-05-05 18:50:51 +00:00
|
|
|
{
|
2009-06-11 18:27:16 +00:00
|
|
|
int fileCount = 0;
|
2009-05-05 18:50:51 +00:00
|
|
|
int bytesWritten = sizeof(SnapshotHeader);
|
|
|
|
// preflight size
|
|
|
|
const int N = snapshot.size();
|
|
|
|
for (int i=0; i<N; i++) {
|
2009-06-11 18:27:16 +00:00
|
|
|
const FileRec& g = snapshot.valueAt(i);
|
|
|
|
if (!g.deleted) {
|
|
|
|
const String8& name = snapshot.keyAt(i);
|
|
|
|
bytesWritten += sizeof(FileState) + round_up(name.length());
|
|
|
|
fileCount++;
|
|
|
|
}
|
2009-05-05 18:50:51 +00:00
|
|
|
}
|
|
|
|
|
2009-05-15 13:07:06 +00:00
|
|
|
LOGP("write_snapshot_file fd=%d\n", fd);
|
|
|
|
|
2009-05-05 18:50:51 +00:00
|
|
|
int amt;
|
2009-06-11 18:27:16 +00:00
|
|
|
SnapshotHeader header = { MAGIC0, fileCount, MAGIC1, bytesWritten };
|
2009-05-05 18:50:51 +00:00
|
|
|
|
|
|
|
amt = write(fd, &header, sizeof(header));
|
|
|
|
if (amt != sizeof(header)) {
|
2012-01-05 23:22:43 +00:00
|
|
|
ALOGW("write_snapshot_file error writing header %s", strerror(errno));
|
2009-05-05 18:50:51 +00:00
|
|
|
return errno;
|
|
|
|
}
|
|
|
|
|
2009-06-11 18:27:16 +00:00
|
|
|
for (int i=0; i<N; i++) {
|
2009-06-11 00:07:15 +00:00
|
|
|
FileRec r = snapshot.valueAt(i);
|
2009-06-11 18:27:16 +00:00
|
|
|
if (!r.deleted) {
|
|
|
|
const String8& name = snapshot.keyAt(i);
|
|
|
|
int nameLen = r.s.nameLen = name.length();
|
2009-05-05 18:50:51 +00:00
|
|
|
|
2009-06-11 18:27:16 +00:00
|
|
|
amt = write(fd, &r.s, sizeof(FileState));
|
|
|
|
if (amt != sizeof(FileState)) {
|
2012-01-05 23:22:43 +00:00
|
|
|
ALOGW("write_snapshot_file error writing header %s", strerror(errno));
|
2009-06-11 18:27:16 +00:00
|
|
|
return 1;
|
|
|
|
}
|
2009-05-05 18:50:51 +00:00
|
|
|
|
2009-06-11 18:27:16 +00:00
|
|
|
// filename is not NULL terminated, but it is padded
|
|
|
|
amt = write(fd, name.string(), nameLen);
|
|
|
|
if (amt != nameLen) {
|
2012-01-05 23:22:43 +00:00
|
|
|
ALOGW("write_snapshot_file error writing filename %s", strerror(errno));
|
2009-05-05 18:50:51 +00:00
|
|
|
return 1;
|
|
|
|
}
|
2009-06-11 18:27:16 +00:00
|
|
|
int paddingLen = ROUND_UP[nameLen % 4];
|
|
|
|
if (paddingLen != 0) {
|
|
|
|
int padding = 0xabababab;
|
|
|
|
amt = write(fd, &padding, paddingLen);
|
|
|
|
if (amt != paddingLen) {
|
2012-01-05 23:22:43 +00:00
|
|
|
ALOGW("write_snapshot_file error writing %d bytes of filename padding %s",
|
2009-06-11 18:27:16 +00:00
|
|
|
paddingLen, strerror(errno));
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
}
|
2009-05-05 18:50:51 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2009-05-19 20:41:21 +00:00
|
|
|
write_delete_file(BackupDataWriter* dataStream, const String8& key)
|
2009-05-05 18:50:51 +00:00
|
|
|
{
|
2009-05-13 22:57:29 +00:00
|
|
|
LOGP("write_delete_file %s\n", key.string());
|
2009-05-19 20:41:21 +00:00
|
|
|
return dataStream->WriteEntityHeader(key, -1);
|
2009-05-05 18:50:51 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2009-06-24 00:35:11 +00:00
|
|
|
write_update_file(BackupDataWriter* dataStream, int fd, int mode, const String8& key,
|
2009-06-11 00:07:15 +00:00
|
|
|
char const* realFilename)
|
2009-05-05 18:50:51 +00:00
|
|
|
{
|
2009-06-24 00:35:11 +00:00
|
|
|
LOGP("write_update_file %s (%s) : mode 0%o\n", realFilename, key.string(), mode);
|
2009-05-05 18:50:51 +00:00
|
|
|
|
|
|
|
const int bufsize = 4*1024;
|
2009-05-19 20:41:21 +00:00
|
|
|
int err;
|
2009-05-05 18:50:51 +00:00
|
|
|
int amt;
|
2009-05-19 20:41:21 +00:00
|
|
|
int fileSize;
|
|
|
|
int bytesLeft;
|
2009-06-24 00:35:11 +00:00
|
|
|
file_metadata_v1 metadata;
|
2009-05-19 20:41:21 +00:00
|
|
|
|
|
|
|
char* buf = (char*)malloc(bufsize);
|
|
|
|
int crc = crc32(0L, Z_NULL, 0);
|
|
|
|
|
|
|
|
|
2009-06-24 00:35:11 +00:00
|
|
|
fileSize = lseek(fd, 0, SEEK_END);
|
2009-05-19 20:41:21 +00:00
|
|
|
lseek(fd, 0, SEEK_SET);
|
|
|
|
|
2009-06-24 00:35:11 +00:00
|
|
|
if (sizeof(metadata) != 16) {
|
2012-01-06 19:20:56 +00:00
|
|
|
ALOGE("ERROR: metadata block is the wrong size!");
|
2009-06-24 00:35:11 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
bytesLeft = fileSize + sizeof(metadata);
|
2009-05-19 20:41:21 +00:00
|
|
|
err = dataStream->WriteEntityHeader(key, bytesLeft);
|
|
|
|
if (err != 0) {
|
2009-06-24 20:57:29 +00:00
|
|
|
free(buf);
|
2009-05-19 20:41:21 +00:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2009-06-24 00:35:11 +00:00
|
|
|
// store the file metadata first
|
|
|
|
metadata.version = tolel(CURRENT_METADATA_VERSION);
|
|
|
|
metadata.mode = tolel(mode);
|
|
|
|
metadata.undefined_1 = metadata.undefined_2 = 0;
|
|
|
|
err = dataStream->WriteEntityData(&metadata, sizeof(metadata));
|
|
|
|
if (err != 0) {
|
2009-06-24 20:57:29 +00:00
|
|
|
free(buf);
|
2009-06-24 00:35:11 +00:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
bytesLeft -= sizeof(metadata); // bytesLeft should == fileSize now
|
|
|
|
|
|
|
|
// now store the file content
|
2009-05-19 20:41:21 +00:00
|
|
|
while ((amt = read(fd, buf, bufsize)) != 0 && bytesLeft > 0) {
|
|
|
|
bytesLeft -= amt;
|
|
|
|
if (bytesLeft < 0) {
|
|
|
|
amt += bytesLeft; // Plus a negative is minus. Don't write more than we promised.
|
|
|
|
}
|
|
|
|
err = dataStream->WriteEntityData(buf, amt);
|
|
|
|
if (err != 0) {
|
2009-06-24 20:57:29 +00:00
|
|
|
free(buf);
|
2009-05-19 20:41:21 +00:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (bytesLeft != 0) {
|
|
|
|
if (bytesLeft > 0) {
|
|
|
|
// Pad out the space we promised in the buffer. We can't corrupt the buffer,
|
|
|
|
// even though the data we're sending is probably bad.
|
|
|
|
memset(buf, 0, bufsize);
|
|
|
|
while (bytesLeft > 0) {
|
|
|
|
amt = bytesLeft < bufsize ? bytesLeft : bufsize;
|
|
|
|
bytesLeft -= amt;
|
|
|
|
err = dataStream->WriteEntityData(buf, amt);
|
|
|
|
if (err != 0) {
|
2009-06-24 20:57:29 +00:00
|
|
|
free(buf);
|
2009-05-19 20:41:21 +00:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2012-01-06 19:20:56 +00:00
|
|
|
ALOGE("write_update_file size mismatch for %s. expected=%d actual=%d."
|
2009-06-11 00:07:15 +00:00
|
|
|
" You aren't doing proper locking!", realFilename, fileSize, fileSize-bytesLeft);
|
2009-05-19 20:41:21 +00:00
|
|
|
}
|
|
|
|
|
2009-06-24 20:57:29 +00:00
|
|
|
free(buf);
|
2009-05-19 20:41:21 +00:00
|
|
|
return NO_ERROR;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2009-06-11 00:07:15 +00:00
|
|
|
write_update_file(BackupDataWriter* dataStream, const String8& key, char const* realFilename)
|
2009-05-19 20:41:21 +00:00
|
|
|
{
|
|
|
|
int err;
|
2009-06-24 00:35:11 +00:00
|
|
|
struct stat st;
|
|
|
|
|
|
|
|
err = stat(realFilename, &st);
|
|
|
|
if (err < 0) {
|
|
|
|
return errno;
|
|
|
|
}
|
|
|
|
|
2009-06-11 00:07:15 +00:00
|
|
|
int fd = open(realFilename, O_RDONLY);
|
2009-05-05 18:50:51 +00:00
|
|
|
if (fd == -1) {
|
2009-05-19 20:41:21 +00:00
|
|
|
return errno;
|
2009-05-05 18:50:51 +00:00
|
|
|
}
|
2009-06-24 00:35:11 +00:00
|
|
|
|
|
|
|
err = write_update_file(dataStream, fd, st.st_mode, key, realFilename);
|
2009-05-19 20:41:21 +00:00
|
|
|
close(fd);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
compute_crc32(int fd)
|
|
|
|
{
|
|
|
|
const int bufsize = 4*1024;
|
|
|
|
int amt;
|
2009-05-05 18:50:51 +00:00
|
|
|
|
|
|
|
char* buf = (char*)malloc(bufsize);
|
|
|
|
int crc = crc32(0L, Z_NULL, 0);
|
|
|
|
|
2009-05-19 20:41:21 +00:00
|
|
|
lseek(fd, 0, SEEK_SET);
|
|
|
|
|
2009-05-05 18:50:51 +00:00
|
|
|
while ((amt = read(fd, buf, bufsize)) != 0) {
|
|
|
|
crc = crc32(crc, (Bytef*)buf, amt);
|
|
|
|
}
|
|
|
|
|
2009-06-24 20:57:29 +00:00
|
|
|
free(buf);
|
2009-05-05 18:50:51 +00:00
|
|
|
return crc;
|
|
|
|
}
|
|
|
|
|
|
|
|
int
|
2009-05-19 20:41:21 +00:00
|
|
|
back_up_files(int oldSnapshotFD, BackupDataWriter* dataStream, int newSnapshotFD,
|
2009-06-11 00:07:15 +00:00
|
|
|
char const* const* files, char const* const* keys, int fileCount)
|
2009-05-05 18:50:51 +00:00
|
|
|
{
|
|
|
|
int err;
|
|
|
|
KeyedVector<String8,FileState> oldSnapshot;
|
2009-06-11 00:07:15 +00:00
|
|
|
KeyedVector<String8,FileRec> newSnapshot;
|
2009-05-05 18:50:51 +00:00
|
|
|
|
|
|
|
if (oldSnapshotFD != -1) {
|
|
|
|
err = read_snapshot_file(oldSnapshotFD, &oldSnapshot);
|
|
|
|
if (err != 0) {
|
|
|
|
// On an error, treat this as a full backup.
|
|
|
|
oldSnapshot.clear();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for (int i=0; i<fileCount; i++) {
|
2009-06-11 00:07:15 +00:00
|
|
|
String8 key(keys[i]);
|
|
|
|
FileRec r;
|
2009-06-18 20:11:18 +00:00
|
|
|
char const* file = files[i];
|
|
|
|
r.file = file;
|
2009-05-05 18:50:51 +00:00
|
|
|
struct stat st;
|
|
|
|
|
2009-06-11 00:07:15 +00:00
|
|
|
err = stat(file, &st);
|
2009-05-05 18:50:51 +00:00
|
|
|
if (err != 0) {
|
2009-06-11 18:27:16 +00:00
|
|
|
r.deleted = true;
|
|
|
|
} else {
|
|
|
|
r.deleted = false;
|
|
|
|
r.s.modTime_sec = st.st_mtime;
|
|
|
|
r.s.modTime_nsec = 0; // workaround sim breakage
|
|
|
|
//r.s.modTime_nsec = st.st_mtime_nsec;
|
2009-06-23 20:03:00 +00:00
|
|
|
r.s.mode = st.st_mode;
|
2009-06-11 18:27:16 +00:00
|
|
|
r.s.size = st.st_size;
|
|
|
|
// we compute the crc32 later down below, when we already have the file open.
|
|
|
|
|
|
|
|
if (newSnapshot.indexOfKey(key) >= 0) {
|
|
|
|
LOGP("back_up_files key already in use '%s'", key.string());
|
|
|
|
return -1;
|
|
|
|
}
|
2009-06-11 00:07:15 +00:00
|
|
|
}
|
|
|
|
newSnapshot.add(key, r);
|
2009-05-05 18:50:51 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
int n = 0;
|
|
|
|
int N = oldSnapshot.size();
|
|
|
|
int m = 0;
|
|
|
|
|
|
|
|
while (n<N && m<fileCount) {
|
|
|
|
const String8& p = oldSnapshot.keyAt(n);
|
|
|
|
const String8& q = newSnapshot.keyAt(m);
|
2009-06-11 18:27:16 +00:00
|
|
|
FileRec& g = newSnapshot.editValueAt(m);
|
2009-05-05 18:50:51 +00:00
|
|
|
int cmp = p.compare(q);
|
2009-06-11 18:27:16 +00:00
|
|
|
if (g.deleted || cmp < 0) {
|
2009-05-05 18:50:51 +00:00
|
|
|
// file removed
|
2009-06-11 00:07:15 +00:00
|
|
|
LOGP("file removed: %s", p.string());
|
2009-06-11 18:27:16 +00:00
|
|
|
g.deleted = true; // They didn't mention the file, but we noticed that it's gone.
|
2009-05-19 20:41:21 +00:00
|
|
|
dataStream->WriteEntityHeader(p, -1);
|
2009-05-05 18:50:51 +00:00
|
|
|
n++;
|
|
|
|
}
|
2009-06-11 18:27:16 +00:00
|
|
|
else if (cmp > 0) {
|
|
|
|
// file added
|
2009-06-18 20:11:18 +00:00
|
|
|
LOGP("file added: %s", g.file.string());
|
|
|
|
write_update_file(dataStream, q, g.file.string());
|
2009-06-11 18:27:16 +00:00
|
|
|
m++;
|
|
|
|
}
|
2009-05-05 18:50:51 +00:00
|
|
|
else {
|
|
|
|
// both files exist, check them
|
|
|
|
const FileState& f = oldSnapshot.valueAt(n);
|
2009-05-19 20:41:21 +00:00
|
|
|
|
2009-06-18 20:11:18 +00:00
|
|
|
int fd = open(g.file.string(), O_RDONLY);
|
2009-06-05 00:01:06 +00:00
|
|
|
if (fd < 0) {
|
2009-05-19 20:41:21 +00:00
|
|
|
// We can't open the file. Don't report it as a delete either. Let the
|
|
|
|
// server keep the old version. Maybe they'll be able to deal with it
|
|
|
|
// on restore.
|
2009-06-18 20:11:18 +00:00
|
|
|
LOGP("Unable to open file %s - skipping", g.file.string());
|
2009-05-19 20:41:21 +00:00
|
|
|
} else {
|
2009-06-11 00:07:15 +00:00
|
|
|
g.s.crc32 = compute_crc32(fd);
|
2009-05-19 20:41:21 +00:00
|
|
|
|
2009-06-11 00:07:15 +00:00
|
|
|
LOGP("%s", q.string());
|
2009-06-23 20:03:00 +00:00
|
|
|
LOGP(" new: modTime=%d,%d mode=%04o size=%-3d crc32=0x%08x",
|
|
|
|
f.modTime_sec, f.modTime_nsec, f.mode, f.size, f.crc32);
|
|
|
|
LOGP(" old: modTime=%d,%d mode=%04o size=%-3d crc32=0x%08x",
|
|
|
|
g.s.modTime_sec, g.s.modTime_nsec, g.s.mode, g.s.size, g.s.crc32);
|
2009-06-11 00:07:15 +00:00
|
|
|
if (f.modTime_sec != g.s.modTime_sec || f.modTime_nsec != g.s.modTime_nsec
|
2009-06-23 20:03:00 +00:00
|
|
|
|| f.mode != g.s.mode || f.size != g.s.size || f.crc32 != g.s.crc32) {
|
2009-06-24 00:35:11 +00:00
|
|
|
write_update_file(dataStream, fd, g.s.mode, p, g.file.string());
|
2009-05-19 20:41:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
close(fd);
|
2009-05-05 18:50:51 +00:00
|
|
|
}
|
|
|
|
n++;
|
|
|
|
m++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// these were deleted
|
|
|
|
while (n<N) {
|
2009-05-19 20:41:21 +00:00
|
|
|
dataStream->WriteEntityHeader(oldSnapshot.keyAt(n), -1);
|
2009-05-05 18:50:51 +00:00
|
|
|
n++;
|
|
|
|
}
|
|
|
|
|
|
|
|
// these were added
|
|
|
|
while (m<fileCount) {
|
|
|
|
const String8& q = newSnapshot.keyAt(m);
|
2009-06-11 00:07:15 +00:00
|
|
|
FileRec& g = newSnapshot.editValueAt(m);
|
2009-06-18 20:11:18 +00:00
|
|
|
write_update_file(dataStream, q, g.file.string());
|
2009-05-05 18:50:51 +00:00
|
|
|
m++;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = write_snapshot_file(newSnapshotFD, newSnapshot);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 21:43:32 +00:00
|
|
|
// Utility function, equivalent to stpcpy(): perform a strcpy, but instead of
|
|
|
|
// returning the initial dest, return a pointer to the trailing NUL.
|
|
|
|
static char* strcpy_ptr(char* dest, const char* str) {
|
|
|
|
if (dest && str) {
|
|
|
|
while ((*dest = *str) != 0) {
|
|
|
|
dest++;
|
|
|
|
str++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return dest;
|
|
|
|
}
|
|
|
|
|
2011-05-13 00:47:12 +00:00
|
|
|
static void calc_tar_checksum(char* buf) {
|
|
|
|
// [ 148 : 8 ] checksum -- to be calculated with this field as space chars
|
|
|
|
memset(buf + 148, ' ', 8);
|
|
|
|
|
|
|
|
uint16_t sum = 0;
|
|
|
|
for (uint8_t* p = (uint8_t*) buf; p < ((uint8_t*)buf) + 512; p++) {
|
|
|
|
sum += *p;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Now write the real checksum value:
|
|
|
|
// [ 148 : 8 ] checksum: 6 octal digits [leading zeroes], NUL, SPC
|
|
|
|
sprintf(buf + 148, "%06o", sum); // the trailing space is already in place
|
|
|
|
}
|
|
|
|
|
2011-05-13 22:38:02 +00:00
|
|
|
// Returns number of bytes written
|
|
|
|
static int write_pax_header_entry(char* buf, const char* key, const char* value) {
|
|
|
|
// start with the size of "1 key=value\n"
|
|
|
|
int len = strlen(key) + strlen(value) + 4;
|
|
|
|
if (len > 9) len++;
|
|
|
|
if (len > 99) len++;
|
|
|
|
if (len > 999) len++;
|
|
|
|
// since PATH_MAX is 4096 we don't expect to have to generate any single
|
|
|
|
// header entry longer than 9999 characters
|
|
|
|
|
|
|
|
return sprintf(buf, "%d %s=%s\n", len, key, value);
|
|
|
|
}
|
|
|
|
|
2011-07-11 18:31:57 +00:00
|
|
|
// Wire format to the backup manager service is chunked: each chunk is prefixed by
|
|
|
|
// a 4-byte count of its size. A chunk size of zero (four zero bytes) indicates EOD.
|
|
|
|
void send_tarfile_chunk(BackupDataWriter* writer, const char* buffer, size_t size) {
|
|
|
|
uint32_t chunk_size_no = htonl(size);
|
|
|
|
writer->WriteEntityData(&chunk_size_no, 4);
|
|
|
|
if (size != 0) writer->WriteEntityData(buffer, size);
|
|
|
|
}
|
|
|
|
|
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 21:43:32 +00:00
|
|
|
int write_tarfile(const String8& packageName, const String8& domain,
|
|
|
|
const String8& rootpath, const String8& filepath, BackupDataWriter* writer)
|
|
|
|
{
|
|
|
|
// In the output stream everything is stored relative to the root
|
|
|
|
const char* relstart = filepath.string() + rootpath.length();
|
|
|
|
if (*relstart == '/') relstart++; // won't be true when path == rootpath
|
|
|
|
String8 relpath(relstart);
|
|
|
|
|
2011-05-13 00:47:12 +00:00
|
|
|
// If relpath is empty, it means this is the top of one of the standard named
|
|
|
|
// domain directories, so we should just skip it
|
|
|
|
if (relpath.length() == 0) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 21:43:32 +00:00
|
|
|
// Too long a name for the ustar format?
|
|
|
|
// "apps/" + packagename + '/' + domainpath < 155 chars
|
|
|
|
// relpath < 100 chars
|
2011-05-13 00:47:12 +00:00
|
|
|
bool needExtended = false;
|
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 21:43:32 +00:00
|
|
|
if ((5 + packageName.length() + 1 + domain.length() >= 155) || (relpath.length() >= 100)) {
|
2011-05-13 00:47:12 +00:00
|
|
|
needExtended = true;
|
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 21:43:32 +00:00
|
|
|
}
|
|
|
|
|
2011-06-07 20:17:17 +00:00
|
|
|
// Non-7bit-clean path also means needing pax extended format
|
2011-05-18 23:28:19 +00:00
|
|
|
if (!needExtended) {
|
|
|
|
for (size_t i = 0; i < filepath.length(); i++) {
|
2011-06-07 20:17:17 +00:00
|
|
|
if ((filepath[i] & 0x80) != 0) {
|
2011-05-18 23:28:19 +00:00
|
|
|
needExtended = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 21:43:32 +00:00
|
|
|
int err = 0;
|
|
|
|
struct stat64 s;
|
|
|
|
if (lstat64(filepath.string(), &s) != 0) {
|
|
|
|
err = errno;
|
2012-01-06 19:20:56 +00:00
|
|
|
ALOGE("Error %d (%s) from lstat64(%s)", err, strerror(err), filepath.string());
|
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 21:43:32 +00:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2011-05-13 00:47:12 +00:00
|
|
|
String8 fullname; // for pax later on
|
|
|
|
String8 prefix;
|
|
|
|
|
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 21:43:32 +00:00
|
|
|
const int isdir = S_ISDIR(s.st_mode);
|
2011-06-09 03:09:31 +00:00
|
|
|
if (isdir) s.st_size = 0; // directories get no actual data in the tar stream
|
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 21:43:32 +00:00
|
|
|
|
|
|
|
// !!! TODO: use mmap when possible to avoid churning the buffer cache
|
|
|
|
// !!! TODO: this will break with symlinks; need to use readlink(2)
|
|
|
|
int fd = open(filepath.string(), O_RDONLY);
|
|
|
|
if (fd < 0) {
|
|
|
|
err = errno;
|
2012-01-06 19:20:56 +00:00
|
|
|
ALOGE("Error %d (%s) from open(%s)", err, strerror(err), filepath.string());
|
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 21:43:32 +00:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
// read/write up to this much at a time.
|
|
|
|
const size_t BUFSIZE = 32 * 1024;
|
|
|
|
char* buf = new char[BUFSIZE];
|
2011-05-13 00:47:12 +00:00
|
|
|
char* paxHeader = buf + 512; // use a different chunk of it as separate scratch
|
|
|
|
char* paxData = buf + 1024;
|
|
|
|
|
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 21:43:32 +00:00
|
|
|
if (buf == NULL) {
|
2012-01-06 19:20:56 +00:00
|
|
|
ALOGE("Out of mem allocating transfer buffer");
|
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 21:43:32 +00:00
|
|
|
err = ENOMEM;
|
2011-05-13 00:47:12 +00:00
|
|
|
goto cleanup;
|
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 21:43:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Good to go -- first construct the standard tar header at the start of the buffer
|
2011-05-13 22:38:02 +00:00
|
|
|
memset(buf, 0, BUFSIZE);
|
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 21:43:32 +00:00
|
|
|
|
|
|
|
// Magic fields for the ustar file format
|
|
|
|
strcat(buf + 257, "ustar");
|
|
|
|
strcat(buf + 263, "00");
|
|
|
|
|
2011-05-13 00:47:12 +00:00
|
|
|
// [ 265 : 32 ] user name, ignored on restore
|
|
|
|
// [ 297 : 32 ] group name, ignored on restore
|
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 21:43:32 +00:00
|
|
|
|
|
|
|
// [ 100 : 8 ] file mode
|
2011-05-13 00:47:12 +00:00
|
|
|
snprintf(buf + 100, 8, "%06o ", s.st_mode & ~S_IFMT);
|
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 21:43:32 +00:00
|
|
|
|
|
|
|
// [ 108 : 8 ] uid -- ignored in Android format; uids are remapped at restore time
|
|
|
|
// [ 116 : 8 ] gid -- ignored in Android format
|
|
|
|
snprintf(buf + 108, 8, "0%lo", s.st_uid);
|
|
|
|
snprintf(buf + 116, 8, "0%lo", s.st_gid);
|
|
|
|
|
|
|
|
// [ 124 : 12 ] file size in bytes
|
2011-05-13 00:47:12 +00:00
|
|
|
if (s.st_size > 077777777777LL) {
|
|
|
|
// very large files need a pax extended size header
|
|
|
|
needExtended = true;
|
|
|
|
}
|
|
|
|
snprintf(buf + 124, 12, "%011llo", (isdir) ? 0LL : s.st_size);
|
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 21:43:32 +00:00
|
|
|
|
|
|
|
// [ 136 : 12 ] last mod time as a UTC time_t
|
|
|
|
snprintf(buf + 136, 12, "%0lo", s.st_mtime);
|
|
|
|
|
|
|
|
// [ 156 : 1 ] link/file type
|
|
|
|
uint8_t type;
|
|
|
|
if (isdir) {
|
|
|
|
type = '5'; // tar magic: '5' == directory
|
|
|
|
} else if (S_ISREG(s.st_mode)) {
|
|
|
|
type = '0'; // tar magic: '0' == normal file
|
|
|
|
} else {
|
2012-01-05 23:22:43 +00:00
|
|
|
ALOGW("Error: unknown file mode 0%o [%s]", s.st_mode, filepath.string());
|
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 21:43:32 +00:00
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
buf[156] = type;
|
|
|
|
|
|
|
|
// [ 157 : 100 ] name of linked file [not implemented]
|
|
|
|
|
|
|
|
{
|
2011-05-13 00:47:12 +00:00
|
|
|
// Prefix and main relative path. Path lengths have been preflighted.
|
|
|
|
if (packageName.length() > 0) {
|
|
|
|
prefix = "apps/";
|
|
|
|
prefix += packageName;
|
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 21:43:32 +00:00
|
|
|
}
|
2011-05-13 00:47:12 +00:00
|
|
|
if (domain.length() > 0) {
|
|
|
|
prefix.appendPath(domain);
|
|
|
|
}
|
|
|
|
|
|
|
|
// pax extended means we don't put in a prefix field, and put a different
|
|
|
|
// string in the basic name field. We can also construct the full path name
|
|
|
|
// out of the substrings we've now built.
|
|
|
|
fullname = prefix;
|
|
|
|
fullname.appendPath(relpath);
|
|
|
|
|
|
|
|
// ustar:
|
|
|
|
// [ 0 : 100 ]; file name/path
|
|
|
|
// [ 345 : 155 ] filename path prefix
|
|
|
|
// We only use the prefix area if fullname won't fit in the path
|
|
|
|
if (fullname.length() > 100) {
|
|
|
|
strncpy(buf, relpath.string(), 100);
|
|
|
|
strncpy(buf + 345, prefix.string(), 155);
|
|
|
|
} else {
|
|
|
|
strncpy(buf, fullname.string(), 100);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// [ 329 : 8 ] and [ 337 : 8 ] devmajor/devminor, not used
|
|
|
|
|
2012-01-04 20:05:49 +00:00
|
|
|
ALOGI(" Name: %s", fullname.string());
|
2011-05-13 00:47:12 +00:00
|
|
|
|
|
|
|
// If we're using a pax extended header, build & write that here; lengths are
|
|
|
|
// already preflighted
|
|
|
|
if (needExtended) {
|
2011-05-13 22:38:02 +00:00
|
|
|
char sizeStr[32]; // big enough for a 64-bit unsigned value in decimal
|
|
|
|
char* p = paxData;
|
|
|
|
|
2011-05-13 00:47:12 +00:00
|
|
|
// construct the pax extended header data block
|
|
|
|
memset(paxData, 0, BUFSIZE - (paxData - buf));
|
|
|
|
int len;
|
|
|
|
|
|
|
|
// size header -- calc len in digits by actually rendering the number
|
|
|
|
// to a string - brute force but simple
|
2011-05-13 22:38:02 +00:00
|
|
|
snprintf(sizeStr, sizeof(sizeStr), "%lld", s.st_size);
|
|
|
|
p += write_pax_header_entry(p, "size", sizeStr);
|
2011-05-13 00:47:12 +00:00
|
|
|
|
|
|
|
// fullname was generated above with the ustar paths
|
2011-05-13 22:38:02 +00:00
|
|
|
p += write_pax_header_entry(p, "path", fullname.string());
|
2011-05-13 00:47:12 +00:00
|
|
|
|
|
|
|
// Now we know how big the pax data is
|
|
|
|
int paxLen = p - paxData;
|
|
|
|
|
|
|
|
// Now build the pax *header* templated on the ustar header
|
|
|
|
memcpy(paxHeader, buf, 512);
|
|
|
|
|
|
|
|
String8 leaf = fullname.getPathLeaf();
|
|
|
|
memset(paxHeader, 0, 100); // rewrite the name area
|
|
|
|
snprintf(paxHeader, 100, "PaxHeader/%s", leaf.string());
|
|
|
|
memset(paxHeader + 345, 0, 155); // rewrite the prefix area
|
|
|
|
strncpy(paxHeader + 345, prefix.string(), 155);
|
|
|
|
|
|
|
|
paxHeader[156] = 'x'; // mark it as a pax extended header
|
|
|
|
|
|
|
|
// [ 124 : 12 ] size of pax extended header data
|
|
|
|
memset(paxHeader + 124, 0, 12);
|
|
|
|
snprintf(paxHeader + 124, 12, "%011o", p - paxData);
|
|
|
|
|
|
|
|
// Checksum and write the pax block header
|
|
|
|
calc_tar_checksum(paxHeader);
|
2011-07-11 18:31:57 +00:00
|
|
|
send_tarfile_chunk(writer, paxHeader, 512);
|
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 21:43:32 +00:00
|
|
|
|
2011-05-13 00:47:12 +00:00
|
|
|
// Now write the pax data itself
|
|
|
|
int paxblocks = (paxLen + 511) / 512;
|
2011-07-11 18:31:57 +00:00
|
|
|
send_tarfile_chunk(writer, paxData, 512 * paxblocks);
|
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 21:43:32 +00:00
|
|
|
}
|
|
|
|
|
2011-05-13 00:47:12 +00:00
|
|
|
// Checksum and write the 512-byte ustar file header block to the output
|
|
|
|
calc_tar_checksum(buf);
|
2011-07-11 18:31:57 +00:00
|
|
|
send_tarfile_chunk(writer, buf, 512);
|
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 21:43:32 +00:00
|
|
|
|
|
|
|
// Now write the file data itself, for real files. We honor tar's convention that
|
|
|
|
// only full 512-byte blocks are sent to write().
|
|
|
|
if (!isdir) {
|
|
|
|
off64_t toWrite = s.st_size;
|
|
|
|
while (toWrite > 0) {
|
|
|
|
size_t toRead = (toWrite < BUFSIZE) ? toWrite : BUFSIZE;
|
|
|
|
ssize_t nRead = read(fd, buf, toRead);
|
|
|
|
if (nRead < 0) {
|
|
|
|
err = errno;
|
2012-01-06 19:20:56 +00:00
|
|
|
ALOGE("Unable to read file [%s], err=%d (%s)", filepath.string(),
|
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 21:43:32 +00:00
|
|
|
err, strerror(err));
|
|
|
|
break;
|
|
|
|
} else if (nRead == 0) {
|
2012-01-06 19:20:56 +00:00
|
|
|
ALOGE("EOF but expect %lld more bytes in [%s]", (long long) toWrite,
|
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 21:43:32 +00:00
|
|
|
filepath.string());
|
|
|
|
err = EIO;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
// At EOF we might have a short block; NUL-pad that to a 512-byte multiple. This
|
|
|
|
// depends on the OS guarantee that for ordinary files, read() will never return
|
|
|
|
// less than the number of bytes requested.
|
|
|
|
ssize_t partial = (nRead+512) % 512;
|
|
|
|
if (partial > 0) {
|
|
|
|
ssize_t remainder = 512 - partial;
|
|
|
|
memset(buf + nRead, 0, remainder);
|
|
|
|
nRead += remainder;
|
|
|
|
}
|
2011-07-11 18:31:57 +00:00
|
|
|
send_tarfile_chunk(writer, buf, nRead);
|
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
2011-04-01 21:43:32 +00:00
|
|
|
toWrite -= nRead;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
cleanup:
|
|
|
|
delete [] buf;
|
|
|
|
done:
|
|
|
|
close(fd);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
// end tarfile
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-18 20:11:18 +00:00
|
|
|
#define RESTORE_BUF_SIZE (8*1024)
|
|
|
|
|
|
|
|
RestoreHelperBase::RestoreHelperBase()
|
|
|
|
{
|
|
|
|
m_buf = malloc(RESTORE_BUF_SIZE);
|
2009-06-24 20:57:29 +00:00
|
|
|
m_loggedUnknownMetadata = false;
|
2009-06-18 20:11:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
RestoreHelperBase::~RestoreHelperBase()
|
|
|
|
{
|
|
|
|
free(m_buf);
|
|
|
|
}
|
|
|
|
|
|
|
|
status_t
|
|
|
|
RestoreHelperBase::WriteFile(const String8& filename, BackupDataReader* in)
|
|
|
|
{
|
|
|
|
ssize_t err;
|
|
|
|
size_t dataSize;
|
|
|
|
String8 key;
|
|
|
|
int fd;
|
|
|
|
void* buf = m_buf;
|
|
|
|
ssize_t amt;
|
|
|
|
int mode;
|
|
|
|
int crc;
|
|
|
|
struct stat st;
|
|
|
|
FileRec r;
|
|
|
|
|
|
|
|
err = in->ReadEntityHeader(&key, &dataSize);
|
|
|
|
if (err != NO_ERROR) {
|
|
|
|
return err;
|
|
|
|
}
|
2009-06-19 01:23:43 +00:00
|
|
|
|
2009-06-24 00:35:11 +00:00
|
|
|
// Get the metadata block off the head of the file entity and use that to
|
|
|
|
// set up the output file
|
|
|
|
file_metadata_v1 metadata;
|
|
|
|
amt = in->ReadEntityData(&metadata, sizeof(metadata));
|
|
|
|
if (amt != sizeof(metadata)) {
|
2012-01-05 23:22:43 +00:00
|
|
|
ALOGW("Could not read metadata for %s -- %ld / %s", filename.string(),
|
2009-06-24 00:35:11 +00:00
|
|
|
(long)amt, strerror(errno));
|
|
|
|
return EIO;
|
|
|
|
}
|
|
|
|
metadata.version = fromlel(metadata.version);
|
|
|
|
metadata.mode = fromlel(metadata.mode);
|
|
|
|
if (metadata.version > CURRENT_METADATA_VERSION) {
|
2009-06-24 20:57:29 +00:00
|
|
|
if (!m_loggedUnknownMetadata) {
|
|
|
|
m_loggedUnknownMetadata = true;
|
2012-01-05 23:22:43 +00:00
|
|
|
ALOGW("Restoring file with unsupported metadata version %d (currently %d)",
|
2009-06-24 20:57:29 +00:00
|
|
|
metadata.version, CURRENT_METADATA_VERSION);
|
|
|
|
}
|
2009-06-24 00:35:11 +00:00
|
|
|
}
|
|
|
|
mode = metadata.mode;
|
2009-06-18 20:11:18 +00:00
|
|
|
|
|
|
|
// Write the file and compute the crc
|
|
|
|
crc = crc32(0L, Z_NULL, 0);
|
2009-06-19 01:23:43 +00:00
|
|
|
fd = open(filename.string(), O_CREAT|O_RDWR|O_TRUNC, mode);
|
|
|
|
if (fd == -1) {
|
2012-01-05 23:22:43 +00:00
|
|
|
ALOGW("Could not open file %s -- %s", filename.string(), strerror(errno));
|
2009-06-18 20:11:18 +00:00
|
|
|
return errno;
|
|
|
|
}
|
|
|
|
|
|
|
|
while ((amt = in->ReadEntityData(buf, RESTORE_BUF_SIZE)) > 0) {
|
|
|
|
err = write(fd, buf, amt);
|
|
|
|
if (err != amt) {
|
|
|
|
close(fd);
|
2012-01-05 23:22:43 +00:00
|
|
|
ALOGW("Error '%s' writing '%s'", strerror(errno), filename.string());
|
2009-06-18 20:11:18 +00:00
|
|
|
return errno;
|
|
|
|
}
|
|
|
|
crc = crc32(crc, (Bytef*)buf, amt);
|
|
|
|
}
|
|
|
|
|
|
|
|
close(fd);
|
|
|
|
|
|
|
|
// Record for the snapshot
|
|
|
|
err = stat(filename.string(), &st);
|
|
|
|
if (err != 0) {
|
2012-01-05 23:22:43 +00:00
|
|
|
ALOGW("Error stating file that we just created %s", filename.string());
|
2009-06-18 20:11:18 +00:00
|
|
|
return errno;
|
|
|
|
}
|
|
|
|
|
|
|
|
r.file = filename;
|
|
|
|
r.deleted = false;
|
|
|
|
r.s.modTime_sec = st.st_mtime;
|
|
|
|
r.s.modTime_nsec = 0; // workaround sim breakage
|
|
|
|
//r.s.modTime_nsec = st.st_mtime_nsec;
|
2009-06-23 20:03:00 +00:00
|
|
|
r.s.mode = st.st_mode;
|
2009-06-18 20:11:18 +00:00
|
|
|
r.s.size = st.st_size;
|
|
|
|
r.s.crc32 = crc;
|
|
|
|
|
|
|
|
m_files.add(key, r);
|
|
|
|
|
|
|
|
return NO_ERROR;
|
|
|
|
}
|
|
|
|
|
|
|
|
status_t
|
|
|
|
RestoreHelperBase::WriteSnapshot(int fd)
|
|
|
|
{
|
|
|
|
return write_snapshot_file(fd, m_files);;
|
|
|
|
}
|
|
|
|
|
2009-05-05 18:50:51 +00:00
|
|
|
#if TEST_BACKUP_HELPERS
|
|
|
|
|
|
|
|
#define SCRATCH_DIR "/data/backup_helper_test/"
|
|
|
|
|
|
|
|
static int
|
|
|
|
write_text_file(const char* path, const char* data)
|
|
|
|
{
|
|
|
|
int amt;
|
|
|
|
int fd;
|
|
|
|
int len;
|
|
|
|
|
|
|
|
fd = creat(path, 0666);
|
|
|
|
if (fd == -1) {
|
|
|
|
fprintf(stderr, "creat %s failed\n", path);
|
|
|
|
return errno;
|
|
|
|
}
|
|
|
|
|
|
|
|
len = strlen(data);
|
|
|
|
amt = write(fd, data, len);
|
|
|
|
if (amt != len) {
|
|
|
|
fprintf(stderr, "error (%s) writing to file %s\n", strerror(errno), path);
|
|
|
|
return errno;
|
|
|
|
}
|
|
|
|
|
|
|
|
close(fd);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
compare_file(const char* path, const unsigned char* data, int len)
|
|
|
|
{
|
|
|
|
int fd;
|
|
|
|
int amt;
|
|
|
|
|
|
|
|
fd = open(path, O_RDONLY);
|
|
|
|
if (fd == -1) {
|
|
|
|
fprintf(stderr, "compare_file error (%s) opening %s\n", strerror(errno), path);
|
|
|
|
return errno;
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned char* contents = (unsigned char*)malloc(len);
|
|
|
|
if (contents == NULL) {
|
|
|
|
fprintf(stderr, "malloc(%d) failed\n", len);
|
|
|
|
return ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool sizesMatch = true;
|
|
|
|
amt = lseek(fd, 0, SEEK_END);
|
|
|
|
if (amt != len) {
|
|
|
|
fprintf(stderr, "compare_file file length should be %d, was %d\n", len, amt);
|
|
|
|
sizesMatch = false;
|
|
|
|
}
|
|
|
|
lseek(fd, 0, SEEK_SET);
|
|
|
|
|
|
|
|
int readLen = amt < len ? amt : len;
|
|
|
|
amt = read(fd, contents, readLen);
|
|
|
|
if (amt != readLen) {
|
|
|
|
fprintf(stderr, "compare_file read expected %d bytes but got %d\n", len, amt);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool contentsMatch = true;
|
|
|
|
for (int i=0; i<readLen; i++) {
|
|
|
|
if (data[i] != contents[i]) {
|
|
|
|
if (contentsMatch) {
|
|
|
|
fprintf(stderr, "compare_file contents are different: (index, expected, actual)\n");
|
|
|
|
contentsMatch = false;
|
|
|
|
}
|
|
|
|
fprintf(stderr, " [%-2d] %02x %02x\n", i, data[i], contents[i]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-06-24 20:57:29 +00:00
|
|
|
free(contents);
|
2009-05-05 18:50:51 +00:00
|
|
|
return contentsMatch && sizesMatch ? 0 : 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
backup_helper_test_empty()
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
int fd;
|
2009-06-11 00:07:15 +00:00
|
|
|
KeyedVector<String8,FileRec> snapshot;
|
2009-05-05 18:50:51 +00:00
|
|
|
const char* filename = SCRATCH_DIR "backup_helper_test_empty.snap";
|
|
|
|
|
|
|
|
system("rm -r " SCRATCH_DIR);
|
|
|
|
mkdir(SCRATCH_DIR, 0777);
|
|
|
|
|
|
|
|
// write
|
|
|
|
fd = creat(filename, 0666);
|
|
|
|
if (fd == -1) {
|
|
|
|
fprintf(stderr, "error creating %s\n", filename);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = write_snapshot_file(fd, snapshot);
|
|
|
|
|
|
|
|
close(fd);
|
|
|
|
|
|
|
|
if (err != 0) {
|
|
|
|
fprintf(stderr, "write_snapshot_file reported error %d (%s)\n", err, strerror(err));
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const unsigned char correct_data[] = {
|
|
|
|
0x53, 0x6e, 0x61, 0x70, 0x00, 0x00, 0x00, 0x00,
|
|
|
|
0x46, 0x69, 0x6c, 0x65, 0x10, 0x00, 0x00, 0x00
|
|
|
|
};
|
|
|
|
|
|
|
|
err = compare_file(filename, correct_data, sizeof(correct_data));
|
|
|
|
if (err != 0) {
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
// read
|
|
|
|
fd = open(filename, O_RDONLY);
|
|
|
|
if (fd == -1) {
|
|
|
|
fprintf(stderr, "error opening for read %s\n", filename);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
KeyedVector<String8,FileState> readSnapshot;
|
|
|
|
err = read_snapshot_file(fd, &readSnapshot);
|
|
|
|
if (err != 0) {
|
|
|
|
fprintf(stderr, "read_snapshot_file failed %d\n", err);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (readSnapshot.size() != 0) {
|
|
|
|
fprintf(stderr, "readSnapshot should be length 0\n");
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
backup_helper_test_four()
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
int fd;
|
2009-06-11 00:07:15 +00:00
|
|
|
KeyedVector<String8,FileRec> snapshot;
|
2009-05-05 18:50:51 +00:00
|
|
|
const char* filename = SCRATCH_DIR "backup_helper_test_four.snap";
|
|
|
|
|
|
|
|
system("rm -r " SCRATCH_DIR);
|
|
|
|
mkdir(SCRATCH_DIR, 0777);
|
|
|
|
|
|
|
|
// write
|
|
|
|
fd = creat(filename, 0666);
|
|
|
|
if (fd == -1) {
|
|
|
|
fprintf(stderr, "error opening %s\n", filename);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
String8 filenames[4];
|
|
|
|
FileState states[4];
|
2009-06-11 00:07:15 +00:00
|
|
|
FileRec r;
|
2009-06-11 18:27:16 +00:00
|
|
|
r.deleted = false;
|
2009-05-05 18:50:51 +00:00
|
|
|
|
|
|
|
states[0].modTime_sec = 0xfedcba98;
|
|
|
|
states[0].modTime_nsec = 0xdeadbeef;
|
2009-06-23 20:03:00 +00:00
|
|
|
states[0].mode = 0777; // decimal 511, hex 0x000001ff
|
2009-05-05 18:50:51 +00:00
|
|
|
states[0].size = 0xababbcbc;
|
|
|
|
states[0].crc32 = 0x12345678;
|
|
|
|
states[0].nameLen = -12;
|
2009-06-11 00:07:15 +00:00
|
|
|
r.s = states[0];
|
2009-05-05 18:50:51 +00:00
|
|
|
filenames[0] = String8("bytes_of_padding");
|
2009-06-11 00:07:15 +00:00
|
|
|
snapshot.add(filenames[0], r);
|
2009-05-05 18:50:51 +00:00
|
|
|
|
|
|
|
states[1].modTime_sec = 0x93400031;
|
|
|
|
states[1].modTime_nsec = 0xdeadbeef;
|
2009-06-23 20:03:00 +00:00
|
|
|
states[1].mode = 0666; // decimal 438, hex 0x000001b6
|
2009-05-05 18:50:51 +00:00
|
|
|
states[1].size = 0x88557766;
|
|
|
|
states[1].crc32 = 0x22334422;
|
|
|
|
states[1].nameLen = -1;
|
2009-06-11 00:07:15 +00:00
|
|
|
r.s = states[1];
|
2009-05-05 18:50:51 +00:00
|
|
|
filenames[1] = String8("bytes_of_padding3");
|
2009-06-11 00:07:15 +00:00
|
|
|
snapshot.add(filenames[1], r);
|
2009-05-05 18:50:51 +00:00
|
|
|
|
|
|
|
states[2].modTime_sec = 0x33221144;
|
|
|
|
states[2].modTime_nsec = 0xdeadbeef;
|
2009-06-23 20:03:00 +00:00
|
|
|
states[2].mode = 0744; // decimal 484, hex 0x000001e4
|
2009-05-05 18:50:51 +00:00
|
|
|
states[2].size = 0x11223344;
|
|
|
|
states[2].crc32 = 0x01122334;
|
|
|
|
states[2].nameLen = 0;
|
2009-06-11 00:07:15 +00:00
|
|
|
r.s = states[2];
|
2009-05-05 18:50:51 +00:00
|
|
|
filenames[2] = String8("bytes_of_padding_2");
|
2009-06-11 00:07:15 +00:00
|
|
|
snapshot.add(filenames[2], r);
|
2009-05-05 18:50:51 +00:00
|
|
|
|
|
|
|
states[3].modTime_sec = 0x33221144;
|
|
|
|
states[3].modTime_nsec = 0xdeadbeef;
|
2009-06-23 20:03:00 +00:00
|
|
|
states[3].mode = 0755; // decimal 493, hex 0x000001ed
|
2009-05-05 18:50:51 +00:00
|
|
|
states[3].size = 0x11223344;
|
|
|
|
states[3].crc32 = 0x01122334;
|
|
|
|
states[3].nameLen = 0;
|
2009-06-11 00:07:15 +00:00
|
|
|
r.s = states[3];
|
2009-05-05 18:50:51 +00:00
|
|
|
filenames[3] = String8("bytes_of_padding__1");
|
2009-06-11 00:07:15 +00:00
|
|
|
snapshot.add(filenames[3], r);
|
2009-05-05 18:50:51 +00:00
|
|
|
|
|
|
|
err = write_snapshot_file(fd, snapshot);
|
|
|
|
|
|
|
|
close(fd);
|
|
|
|
|
|
|
|
if (err != 0) {
|
|
|
|
fprintf(stderr, "write_snapshot_file reported error %d (%s)\n", err, strerror(err));
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const unsigned char correct_data[] = {
|
|
|
|
// header
|
|
|
|
0x53, 0x6e, 0x61, 0x70, 0x04, 0x00, 0x00, 0x00,
|
2009-06-23 20:03:00 +00:00
|
|
|
0x46, 0x69, 0x6c, 0x65, 0xbc, 0x00, 0x00, 0x00,
|
2009-05-05 18:50:51 +00:00
|
|
|
|
|
|
|
// bytes_of_padding
|
|
|
|
0x98, 0xba, 0xdc, 0xfe, 0xef, 0xbe, 0xad, 0xde,
|
2009-06-23 20:03:00 +00:00
|
|
|
0xff, 0x01, 0x00, 0x00, 0xbc, 0xbc, 0xab, 0xab,
|
|
|
|
0x78, 0x56, 0x34, 0x12, 0x10, 0x00, 0x00, 0x00,
|
|
|
|
0x62, 0x79, 0x74, 0x65, 0x73, 0x5f, 0x6f, 0x66,
|
|
|
|
0x5f, 0x70, 0x61, 0x64, 0x64, 0x69, 0x6e, 0x67,
|
2009-05-05 18:50:51 +00:00
|
|
|
|
|
|
|
// bytes_of_padding3
|
|
|
|
0x31, 0x00, 0x40, 0x93, 0xef, 0xbe, 0xad, 0xde,
|
2009-06-23 20:03:00 +00:00
|
|
|
0xb6, 0x01, 0x00, 0x00, 0x66, 0x77, 0x55, 0x88,
|
|
|
|
0x22, 0x44, 0x33, 0x22, 0x11, 0x00, 0x00, 0x00,
|
|
|
|
0x62, 0x79, 0x74, 0x65, 0x73, 0x5f, 0x6f, 0x66,
|
|
|
|
0x5f, 0x70, 0x61, 0x64, 0x64, 0x69, 0x6e, 0x67,
|
|
|
|
0x33, 0xab, 0xab, 0xab,
|
2009-05-22 20:41:38 +00:00
|
|
|
|
2009-05-05 18:50:51 +00:00
|
|
|
// bytes of padding2
|
|
|
|
0x44, 0x11, 0x22, 0x33, 0xef, 0xbe, 0xad, 0xde,
|
2009-06-23 20:03:00 +00:00
|
|
|
0xe4, 0x01, 0x00, 0x00, 0x44, 0x33, 0x22, 0x11,
|
|
|
|
0x34, 0x23, 0x12, 0x01, 0x12, 0x00, 0x00, 0x00,
|
|
|
|
0x62, 0x79, 0x74, 0x65, 0x73, 0x5f, 0x6f, 0x66,
|
|
|
|
0x5f, 0x70, 0x61, 0x64, 0x64, 0x69, 0x6e, 0x67,
|
|
|
|
0x5f, 0x32, 0xab, 0xab,
|
2009-05-22 20:41:38 +00:00
|
|
|
|
2009-05-05 18:50:51 +00:00
|
|
|
// bytes of padding3
|
|
|
|
0x44, 0x11, 0x22, 0x33, 0xef, 0xbe, 0xad, 0xde,
|
2009-06-23 20:03:00 +00:00
|
|
|
0xed, 0x01, 0x00, 0x00, 0x44, 0x33, 0x22, 0x11,
|
|
|
|
0x34, 0x23, 0x12, 0x01, 0x13, 0x00, 0x00, 0x00,
|
|
|
|
0x62, 0x79, 0x74, 0x65, 0x73, 0x5f, 0x6f, 0x66,
|
|
|
|
0x5f, 0x70, 0x61, 0x64, 0x64, 0x69, 0x6e, 0x67,
|
|
|
|
0x5f, 0x5f, 0x31, 0xab
|
2009-05-05 18:50:51 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
err = compare_file(filename, correct_data, sizeof(correct_data));
|
|
|
|
if (err != 0) {
|
|
|
|
return err;
|
|
|
|
}
|
2009-05-22 20:41:38 +00:00
|
|
|
|
2009-05-05 18:50:51 +00:00
|
|
|
// read
|
|
|
|
fd = open(filename, O_RDONLY);
|
|
|
|
if (fd == -1) {
|
|
|
|
fprintf(stderr, "error opening for read %s\n", filename);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
KeyedVector<String8,FileState> readSnapshot;
|
|
|
|
err = read_snapshot_file(fd, &readSnapshot);
|
|
|
|
if (err != 0) {
|
|
|
|
fprintf(stderr, "read_snapshot_file failed %d\n", err);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (readSnapshot.size() != 4) {
|
|
|
|
fprintf(stderr, "readSnapshot should be length 4 is %d\n", readSnapshot.size());
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool matched = true;
|
|
|
|
for (size_t i=0; i<readSnapshot.size(); i++) {
|
|
|
|
const String8& name = readSnapshot.keyAt(i);
|
|
|
|
const FileState state = readSnapshot.valueAt(i);
|
|
|
|
|
|
|
|
if (name != filenames[i] || states[i].modTime_sec != state.modTime_sec
|
2009-06-23 20:03:00 +00:00
|
|
|
|| states[i].modTime_nsec != state.modTime_nsec || states[i].mode != state.mode
|
2009-05-05 18:50:51 +00:00
|
|
|
|| states[i].size != state.size || states[i].crc32 != states[i].crc32) {
|
2009-06-23 20:03:00 +00:00
|
|
|
fprintf(stderr, "state %d expected={%d/%d, 0x%08x, %04o, 0x%08x, %3d} '%s'\n"
|
|
|
|
" actual={%d/%d, 0x%08x, %04o, 0x%08x, %3d} '%s'\n", i,
|
|
|
|
states[i].modTime_sec, states[i].modTime_nsec, states[i].mode, states[i].size,
|
|
|
|
states[i].crc32, name.length(), filenames[i].string(),
|
|
|
|
state.modTime_sec, state.modTime_nsec, state.mode, state.size, state.crc32,
|
|
|
|
state.nameLen, name.string());
|
2009-05-05 18:50:51 +00:00
|
|
|
matched = false;
|
|
|
|
}
|
|
|
|
}
|
2009-05-22 20:41:38 +00:00
|
|
|
|
2009-05-05 18:50:51 +00:00
|
|
|
return matched ? 0 : 1;
|
|
|
|
}
|
|
|
|
|
2009-05-15 13:07:06 +00:00
|
|
|
// hexdump -v -e '" " 8/1 " 0x%02x," "\n"' data_writer.data
|
|
|
|
const unsigned char DATA_GOLDEN_FILE[] = {
|
2009-05-15 22:20:19 +00:00
|
|
|
0x44, 0x61, 0x74, 0x61, 0x0b, 0x00, 0x00, 0x00,
|
|
|
|
0x0c, 0x00, 0x00, 0x00, 0x6e, 0x6f, 0x5f, 0x70,
|
2009-05-15 13:07:06 +00:00
|
|
|
0x61, 0x64, 0x64, 0x69, 0x6e, 0x67, 0x5f, 0x00,
|
2009-05-15 22:20:19 +00:00
|
|
|
0x6e, 0x6f, 0x5f, 0x70, 0x61, 0x64, 0x64, 0x69,
|
2009-06-16 20:31:35 +00:00
|
|
|
0x6e, 0x67, 0x5f, 0x00, 0x44, 0x61, 0x74, 0x61,
|
|
|
|
0x0c, 0x00, 0x00, 0x00, 0x0d, 0x00, 0x00, 0x00,
|
2009-05-15 13:07:06 +00:00
|
|
|
0x70, 0x61, 0x64, 0x64, 0x65, 0x64, 0x5f, 0x74,
|
|
|
|
0x6f, 0x5f, 0x5f, 0x33, 0x00, 0xbc, 0xbc, 0xbc,
|
|
|
|
0x70, 0x61, 0x64, 0x64, 0x65, 0x64, 0x5f, 0x74,
|
2009-06-16 20:31:35 +00:00
|
|
|
0x6f, 0x5f, 0x5f, 0x33, 0x00, 0xbc, 0xbc, 0xbc,
|
2009-05-15 22:20:19 +00:00
|
|
|
0x44, 0x61, 0x74, 0x61, 0x0d, 0x00, 0x00, 0x00,
|
|
|
|
0x0e, 0x00, 0x00, 0x00, 0x70, 0x61, 0x64, 0x64,
|
|
|
|
0x65, 0x64, 0x5f, 0x74, 0x6f, 0x5f, 0x32, 0x5f,
|
|
|
|
0x5f, 0x00, 0xbc, 0xbc, 0x70, 0x61, 0x64, 0x64,
|
|
|
|
0x65, 0x64, 0x5f, 0x74, 0x6f, 0x5f, 0x32, 0x5f,
|
2009-06-16 20:31:35 +00:00
|
|
|
0x5f, 0x00, 0xbc, 0xbc, 0x44, 0x61, 0x74, 0x61,
|
2009-05-15 13:07:06 +00:00
|
|
|
0x0a, 0x00, 0x00, 0x00, 0x0b, 0x00, 0x00, 0x00,
|
|
|
|
0x70, 0x61, 0x64, 0x64, 0x65, 0x64, 0x5f, 0x74,
|
|
|
|
0x6f, 0x31, 0x00, 0xbc, 0x70, 0x61, 0x64, 0x64,
|
2009-06-16 20:31:35 +00:00
|
|
|
0x65, 0x64, 0x5f, 0x74, 0x6f, 0x31, 0x00
|
|
|
|
|
2009-05-15 13:07:06 +00:00
|
|
|
};
|
|
|
|
const int DATA_GOLDEN_FILE_SIZE = sizeof(DATA_GOLDEN_FILE);
|
|
|
|
|
|
|
|
static int
|
|
|
|
test_write_header_and_entity(BackupDataWriter& writer, const char* str)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
String8 text(str);
|
|
|
|
|
|
|
|
err = writer.WriteEntityHeader(text, text.length()+1);
|
|
|
|
if (err != 0) {
|
|
|
|
fprintf(stderr, "WriteEntityHeader failed with %s\n", strerror(err));
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = writer.WriteEntityData(text.string(), text.length()+1);
|
|
|
|
if (err != 0) {
|
|
|
|
fprintf(stderr, "write failed for data '%s'\n", text.string());
|
|
|
|
return errno;
|
|
|
|
}
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
backup_helper_test_data_writer()
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
int fd;
|
|
|
|
const char* filename = SCRATCH_DIR "data_writer.data";
|
|
|
|
|
|
|
|
system("rm -r " SCRATCH_DIR);
|
|
|
|
mkdir(SCRATCH_DIR, 0777);
|
|
|
|
mkdir(SCRATCH_DIR "data", 0777);
|
2009-05-22 20:41:38 +00:00
|
|
|
|
2009-05-15 13:07:06 +00:00
|
|
|
fd = creat(filename, 0666);
|
|
|
|
if (fd == -1) {
|
|
|
|
fprintf(stderr, "error creating: %s\n", strerror(errno));
|
|
|
|
return errno;
|
|
|
|
}
|
|
|
|
|
|
|
|
BackupDataWriter writer(fd);
|
|
|
|
|
|
|
|
err = 0;
|
|
|
|
err |= test_write_header_and_entity(writer, "no_padding_");
|
|
|
|
err |= test_write_header_and_entity(writer, "padded_to__3");
|
|
|
|
err |= test_write_header_and_entity(writer, "padded_to_2__");
|
|
|
|
err |= test_write_header_and_entity(writer, "padded_to1");
|
|
|
|
|
|
|
|
close(fd);
|
|
|
|
|
|
|
|
err = compare_file(filename, DATA_GOLDEN_FILE, DATA_GOLDEN_FILE_SIZE);
|
|
|
|
if (err != 0) {
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2009-05-15 22:20:19 +00:00
|
|
|
int
|
|
|
|
test_read_header_and_entity(BackupDataReader& reader, const char* str)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
int bufSize = strlen(str)+1;
|
|
|
|
char* buf = (char*)malloc(bufSize);
|
|
|
|
String8 string;
|
|
|
|
int cookie = 0x11111111;
|
|
|
|
size_t actualSize;
|
2009-06-16 20:31:35 +00:00
|
|
|
bool done;
|
|
|
|
int type;
|
2009-06-23 20:03:00 +00:00
|
|
|
ssize_t nRead;
|
2009-05-15 22:20:19 +00:00
|
|
|
|
|
|
|
// printf("\n\n---------- test_read_header_and_entity -- %s\n\n", str);
|
|
|
|
|
2009-06-16 20:31:35 +00:00
|
|
|
err = reader.ReadNextHeader(&done, &type);
|
|
|
|
if (done) {
|
|
|
|
fprintf(stderr, "should not be done yet\n");
|
|
|
|
goto finished;
|
2009-05-15 22:20:19 +00:00
|
|
|
}
|
|
|
|
if (err != 0) {
|
2009-06-16 20:31:35 +00:00
|
|
|
fprintf(stderr, "ReadNextHeader (for app header) failed with %s\n", strerror(err));
|
|
|
|
goto finished;
|
2009-05-15 22:20:19 +00:00
|
|
|
}
|
2009-06-16 20:31:35 +00:00
|
|
|
if (type != BACKUP_HEADER_ENTITY_V1) {
|
2009-05-15 22:20:19 +00:00
|
|
|
err = EINVAL;
|
2009-06-16 20:31:35 +00:00
|
|
|
fprintf(stderr, "type=0x%08x expected 0x%08x\n", type, BACKUP_HEADER_ENTITY_V1);
|
2009-05-15 22:20:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
err = reader.ReadEntityHeader(&string, &actualSize);
|
|
|
|
if (err != 0) {
|
|
|
|
fprintf(stderr, "ReadEntityHeader failed with %s\n", strerror(err));
|
2009-06-16 20:31:35 +00:00
|
|
|
goto finished;
|
2009-05-15 22:20:19 +00:00
|
|
|
}
|
|
|
|
if (string != str) {
|
|
|
|
fprintf(stderr, "ReadEntityHeader expected key '%s' got '%s'\n", str, string.string());
|
|
|
|
err = EINVAL;
|
2009-06-16 20:31:35 +00:00
|
|
|
goto finished;
|
2009-05-15 22:20:19 +00:00
|
|
|
}
|
|
|
|
if ((int)actualSize != bufSize) {
|
|
|
|
fprintf(stderr, "ReadEntityHeader expected dataSize 0x%08x got 0x%08x\n", bufSize,
|
|
|
|
actualSize);
|
|
|
|
err = EINVAL;
|
2009-06-16 20:31:35 +00:00
|
|
|
goto finished;
|
2009-05-15 22:20:19 +00:00
|
|
|
}
|
|
|
|
|
2009-06-23 20:03:00 +00:00
|
|
|
nRead = reader.ReadEntityData(buf, bufSize);
|
|
|
|
if (nRead < 0) {
|
|
|
|
err = reader.Status();
|
2009-05-15 22:20:19 +00:00
|
|
|
fprintf(stderr, "ReadEntityData failed with %s\n", strerror(err));
|
2009-06-16 20:31:35 +00:00
|
|
|
goto finished;
|
2009-05-15 22:20:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (0 != memcmp(buf, str, bufSize)) {
|
|
|
|
fprintf(stderr, "ReadEntityData expected '%s' but got something starting with "
|
2009-06-16 20:31:35 +00:00
|
|
|
"%02x %02x %02x %02x '%c%c%c%c'\n", str, buf[0], buf[1], buf[2], buf[3],
|
|
|
|
buf[0], buf[1], buf[2], buf[3]);
|
2009-05-15 22:20:19 +00:00
|
|
|
err = EINVAL;
|
2009-06-16 20:31:35 +00:00
|
|
|
goto finished;
|
2009-05-15 22:20:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// The next read will confirm whether it got the right amount of data.
|
|
|
|
|
2009-06-16 20:31:35 +00:00
|
|
|
finished:
|
2009-05-15 22:20:19 +00:00
|
|
|
if (err != NO_ERROR) {
|
|
|
|
fprintf(stderr, "test_read_header_and_entity failed with %s\n", strerror(err));
|
|
|
|
}
|
2009-06-24 20:57:29 +00:00
|
|
|
free(buf);
|
2009-05-15 22:20:19 +00:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
backup_helper_test_data_reader()
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
int fd;
|
|
|
|
const char* filename = SCRATCH_DIR "data_reader.data";
|
|
|
|
|
|
|
|
system("rm -r " SCRATCH_DIR);
|
|
|
|
mkdir(SCRATCH_DIR, 0777);
|
|
|
|
mkdir(SCRATCH_DIR "data", 0777);
|
2009-05-22 20:41:38 +00:00
|
|
|
|
2009-05-15 22:20:19 +00:00
|
|
|
fd = creat(filename, 0666);
|
|
|
|
if (fd == -1) {
|
|
|
|
fprintf(stderr, "error creating: %s\n", strerror(errno));
|
|
|
|
return errno;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = write(fd, DATA_GOLDEN_FILE, DATA_GOLDEN_FILE_SIZE);
|
|
|
|
if (err != DATA_GOLDEN_FILE_SIZE) {
|
|
|
|
fprintf(stderr, "Error \"%s\" writing golden file %s\n", strerror(errno), filename);
|
|
|
|
return errno;
|
|
|
|
}
|
|
|
|
|
|
|
|
close(fd);
|
|
|
|
|
|
|
|
fd = open(filename, O_RDONLY);
|
|
|
|
if (fd == -1) {
|
|
|
|
fprintf(stderr, "Error \"%s\" opening golden file %s for read\n", strerror(errno),
|
|
|
|
filename);
|
|
|
|
return errno;
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
BackupDataReader reader(fd);
|
|
|
|
|
|
|
|
err = 0;
|
|
|
|
|
|
|
|
if (err == NO_ERROR) {
|
|
|
|
err = test_read_header_and_entity(reader, "no_padding_");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (err == NO_ERROR) {
|
|
|
|
err = test_read_header_and_entity(reader, "padded_to__3");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (err == NO_ERROR) {
|
|
|
|
err = test_read_header_and_entity(reader, "padded_to_2__");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (err == NO_ERROR) {
|
|
|
|
err = test_read_header_and_entity(reader, "padded_to1");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
close(fd);
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2009-05-05 18:50:51 +00:00
|
|
|
static int
|
|
|
|
get_mod_time(const char* filename, struct timeval times[2])
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
struct stat64 st;
|
|
|
|
err = stat64(filename, &st);
|
|
|
|
if (err != 0) {
|
|
|
|
fprintf(stderr, "stat '%s' failed: %s\n", filename, strerror(errno));
|
|
|
|
return errno;
|
|
|
|
}
|
|
|
|
times[0].tv_sec = st.st_atime;
|
|
|
|
times[1].tv_sec = st.st_mtime;
|
2009-05-22 20:41:38 +00:00
|
|
|
|
|
|
|
// If st_atime is a macro then struct stat64 uses struct timespec
|
|
|
|
// to store the access and modif time values and typically
|
|
|
|
// st_*time_nsec is not defined. In glibc, this is controlled by
|
|
|
|
// __USE_MISC.
|
|
|
|
#ifdef __USE_MISC
|
|
|
|
#if !defined(st_atime) || defined(st_atime_nsec)
|
|
|
|
#error "Check if this __USE_MISC conditional is still needed."
|
|
|
|
#endif
|
|
|
|
times[0].tv_usec = st.st_atim.tv_nsec / 1000;
|
|
|
|
times[1].tv_usec = st.st_mtim.tv_nsec / 1000;
|
|
|
|
#else
|
|
|
|
times[0].tv_usec = st.st_atime_nsec / 1000;
|
2009-05-05 18:50:51 +00:00
|
|
|
times[1].tv_usec = st.st_mtime_nsec / 1000;
|
2009-05-22 20:41:38 +00:00
|
|
|
#endif
|
|
|
|
|
2009-05-05 18:50:51 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
backup_helper_test_files()
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
int oldSnapshotFD;
|
2009-05-15 13:07:06 +00:00
|
|
|
int dataStreamFD;
|
|
|
|
int newSnapshotFD;
|
2009-05-05 18:50:51 +00:00
|
|
|
|
|
|
|
system("rm -r " SCRATCH_DIR);
|
|
|
|
mkdir(SCRATCH_DIR, 0777);
|
|
|
|
mkdir(SCRATCH_DIR "data", 0777);
|
|
|
|
|
|
|
|
write_text_file(SCRATCH_DIR "data/b", "b\nbb\n");
|
|
|
|
write_text_file(SCRATCH_DIR "data/c", "c\ncc\n");
|
|
|
|
write_text_file(SCRATCH_DIR "data/d", "d\ndd\n");
|
|
|
|
write_text_file(SCRATCH_DIR "data/e", "e\nee\n");
|
|
|
|
write_text_file(SCRATCH_DIR "data/f", "f\nff\n");
|
|
|
|
write_text_file(SCRATCH_DIR "data/h", "h\nhh\n");
|
|
|
|
|
|
|
|
char const* files_before[] = {
|
2009-06-11 00:07:15 +00:00
|
|
|
SCRATCH_DIR "data/b",
|
|
|
|
SCRATCH_DIR "data/c",
|
|
|
|
SCRATCH_DIR "data/d",
|
|
|
|
SCRATCH_DIR "data/e",
|
|
|
|
SCRATCH_DIR "data/f"
|
|
|
|
};
|
|
|
|
|
|
|
|
char const* keys_before[] = {
|
2009-05-05 18:50:51 +00:00
|
|
|
"data/b",
|
|
|
|
"data/c",
|
|
|
|
"data/d",
|
|
|
|
"data/e",
|
|
|
|
"data/f"
|
|
|
|
};
|
|
|
|
|
2009-05-15 13:07:06 +00:00
|
|
|
dataStreamFD = creat(SCRATCH_DIR "1.data", 0666);
|
|
|
|
if (dataStreamFD == -1) {
|
|
|
|
fprintf(stderr, "error creating: %s\n", strerror(errno));
|
|
|
|
return errno;
|
|
|
|
}
|
|
|
|
|
2009-05-05 18:50:51 +00:00
|
|
|
newSnapshotFD = creat(SCRATCH_DIR "before.snap", 0666);
|
|
|
|
if (newSnapshotFD == -1) {
|
|
|
|
fprintf(stderr, "error creating: %s\n", strerror(errno));
|
|
|
|
return errno;
|
|
|
|
}
|
2009-05-19 20:41:21 +00:00
|
|
|
|
|
|
|
{
|
|
|
|
BackupDataWriter dataStream(dataStreamFD);
|
2009-05-22 20:41:38 +00:00
|
|
|
|
2009-06-11 00:07:15 +00:00
|
|
|
err = back_up_files(-1, &dataStream, newSnapshotFD, files_before, keys_before, 5);
|
2009-05-19 20:41:21 +00:00
|
|
|
if (err != 0) {
|
|
|
|
return err;
|
|
|
|
}
|
2009-05-05 18:50:51 +00:00
|
|
|
}
|
|
|
|
|
2009-05-15 13:07:06 +00:00
|
|
|
close(dataStreamFD);
|
2009-05-05 18:50:51 +00:00
|
|
|
close(newSnapshotFD);
|
|
|
|
|
|
|
|
sleep(3);
|
|
|
|
|
|
|
|
struct timeval d_times[2];
|
|
|
|
struct timeval e_times[2];
|
|
|
|
|
|
|
|
err = get_mod_time(SCRATCH_DIR "data/d", d_times);
|
|
|
|
err |= get_mod_time(SCRATCH_DIR "data/e", e_times);
|
|
|
|
if (err != 0) {
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
write_text_file(SCRATCH_DIR "data/a", "a\naa\n");
|
|
|
|
unlink(SCRATCH_DIR "data/c");
|
|
|
|
write_text_file(SCRATCH_DIR "data/c", "c\ncc\n");
|
|
|
|
write_text_file(SCRATCH_DIR "data/d", "dd\ndd\n");
|
|
|
|
utimes(SCRATCH_DIR "data/d", d_times);
|
|
|
|
write_text_file(SCRATCH_DIR "data/e", "z\nzz\n");
|
|
|
|
utimes(SCRATCH_DIR "data/e", e_times);
|
|
|
|
write_text_file(SCRATCH_DIR "data/g", "g\ngg\n");
|
|
|
|
unlink(SCRATCH_DIR "data/f");
|
2009-05-22 20:41:38 +00:00
|
|
|
|
2009-05-05 18:50:51 +00:00
|
|
|
char const* files_after[] = {
|
2009-06-11 00:07:15 +00:00
|
|
|
SCRATCH_DIR "data/a", // added
|
|
|
|
SCRATCH_DIR "data/b", // same
|
|
|
|
SCRATCH_DIR "data/c", // different mod time
|
|
|
|
SCRATCH_DIR "data/d", // different size (same mod time)
|
|
|
|
SCRATCH_DIR "data/e", // different contents (same mod time, same size)
|
|
|
|
SCRATCH_DIR "data/g" // added
|
|
|
|
};
|
|
|
|
|
|
|
|
char const* keys_after[] = {
|
2009-05-05 18:50:51 +00:00
|
|
|
"data/a", // added
|
|
|
|
"data/b", // same
|
|
|
|
"data/c", // different mod time
|
|
|
|
"data/d", // different size (same mod time)
|
|
|
|
"data/e", // different contents (same mod time, same size)
|
|
|
|
"data/g" // added
|
|
|
|
};
|
|
|
|
|
|
|
|
oldSnapshotFD = open(SCRATCH_DIR "before.snap", O_RDONLY);
|
|
|
|
if (oldSnapshotFD == -1) {
|
|
|
|
fprintf(stderr, "error opening: %s\n", strerror(errno));
|
|
|
|
return errno;
|
|
|
|
}
|
|
|
|
|
2009-05-15 13:07:06 +00:00
|
|
|
dataStreamFD = creat(SCRATCH_DIR "2.data", 0666);
|
|
|
|
if (dataStreamFD == -1) {
|
|
|
|
fprintf(stderr, "error creating: %s\n", strerror(errno));
|
|
|
|
return errno;
|
|
|
|
}
|
|
|
|
|
2009-05-05 18:50:51 +00:00
|
|
|
newSnapshotFD = creat(SCRATCH_DIR "after.snap", 0666);
|
|
|
|
if (newSnapshotFD == -1) {
|
|
|
|
fprintf(stderr, "error creating: %s\n", strerror(errno));
|
|
|
|
return errno;
|
|
|
|
}
|
|
|
|
|
2009-05-19 20:41:21 +00:00
|
|
|
{
|
|
|
|
BackupDataWriter dataStream(dataStreamFD);
|
2009-05-22 20:41:38 +00:00
|
|
|
|
2009-06-11 00:07:15 +00:00
|
|
|
err = back_up_files(oldSnapshotFD, &dataStream, newSnapshotFD, files_after, keys_after, 6);
|
2009-05-19 20:41:21 +00:00
|
|
|
if (err != 0) {
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
}
|
2009-05-05 18:50:51 +00:00
|
|
|
|
|
|
|
close(oldSnapshotFD);
|
2009-05-15 13:07:06 +00:00
|
|
|
close(dataStreamFD);
|
2009-05-05 18:50:51 +00:00
|
|
|
close(newSnapshotFD);
|
2009-05-22 20:41:38 +00:00
|
|
|
|
2009-05-05 18:50:51 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-06-11 00:07:15 +00:00
|
|
|
int
|
|
|
|
backup_helper_test_null_base()
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
int oldSnapshotFD;
|
|
|
|
int dataStreamFD;
|
|
|
|
int newSnapshotFD;
|
|
|
|
|
|
|
|
system("rm -r " SCRATCH_DIR);
|
|
|
|
mkdir(SCRATCH_DIR, 0777);
|
|
|
|
mkdir(SCRATCH_DIR "data", 0777);
|
|
|
|
|
|
|
|
write_text_file(SCRATCH_DIR "data/a", "a\naa\n");
|
|
|
|
|
|
|
|
char const* files[] = {
|
|
|
|
SCRATCH_DIR "data/a",
|
|
|
|
};
|
|
|
|
|
|
|
|
char const* keys[] = {
|
|
|
|
"a",
|
|
|
|
};
|
|
|
|
|
|
|
|
dataStreamFD = creat(SCRATCH_DIR "null_base.data", 0666);
|
|
|
|
if (dataStreamFD == -1) {
|
|
|
|
fprintf(stderr, "error creating: %s\n", strerror(errno));
|
|
|
|
return errno;
|
|
|
|
}
|
|
|
|
|
|
|
|
newSnapshotFD = creat(SCRATCH_DIR "null_base.snap", 0666);
|
|
|
|
if (newSnapshotFD == -1) {
|
|
|
|
fprintf(stderr, "error creating: %s\n", strerror(errno));
|
|
|
|
return errno;
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
BackupDataWriter dataStream(dataStreamFD);
|
|
|
|
|
|
|
|
err = back_up_files(-1, &dataStream, newSnapshotFD, files, keys, 1);
|
|
|
|
if (err != 0) {
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
close(dataStreamFD);
|
|
|
|
close(newSnapshotFD);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-06-11 18:27:16 +00:00
|
|
|
int
|
|
|
|
backup_helper_test_missing_file()
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
int oldSnapshotFD;
|
|
|
|
int dataStreamFD;
|
|
|
|
int newSnapshotFD;
|
|
|
|
|
|
|
|
system("rm -r " SCRATCH_DIR);
|
|
|
|
mkdir(SCRATCH_DIR, 0777);
|
|
|
|
mkdir(SCRATCH_DIR "data", 0777);
|
|
|
|
|
|
|
|
write_text_file(SCRATCH_DIR "data/b", "b\nbb\n");
|
|
|
|
|
|
|
|
char const* files[] = {
|
|
|
|
SCRATCH_DIR "data/a",
|
|
|
|
SCRATCH_DIR "data/b",
|
|
|
|
SCRATCH_DIR "data/c",
|
|
|
|
};
|
|
|
|
|
|
|
|
char const* keys[] = {
|
|
|
|
"a",
|
|
|
|
"b",
|
|
|
|
"c",
|
|
|
|
};
|
|
|
|
|
|
|
|
dataStreamFD = creat(SCRATCH_DIR "null_base.data", 0666);
|
|
|
|
if (dataStreamFD == -1) {
|
|
|
|
fprintf(stderr, "error creating: %s\n", strerror(errno));
|
|
|
|
return errno;
|
|
|
|
}
|
|
|
|
|
|
|
|
newSnapshotFD = creat(SCRATCH_DIR "null_base.snap", 0666);
|
|
|
|
if (newSnapshotFD == -1) {
|
|
|
|
fprintf(stderr, "error creating: %s\n", strerror(errno));
|
|
|
|
return errno;
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
BackupDataWriter dataStream(dataStreamFD);
|
|
|
|
|
|
|
|
err = back_up_files(-1, &dataStream, newSnapshotFD, files, keys, 1);
|
|
|
|
if (err != 0) {
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
close(dataStreamFD);
|
|
|
|
close(newSnapshotFD);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-06-11 00:07:15 +00:00
|
|
|
|
2009-05-05 18:50:51 +00:00
|
|
|
#endif // TEST_BACKUP_HELPERS
|
2009-05-15 13:07:06 +00:00
|
|
|
|
|
|
|
}
|