Filezilla + ClockworkMod backup corruption adventure

One of the CyanogenMod devs advised, in response to a post about corrupted filesystems,  that users not mount the microSDHC in the phone via USB.  Ok.  I loaded the FTP Server app on my phone and installed filezilla to move the files back and forth.

The main thing I move is backups;  I make many, particularly if I am bug testing or removing unused .apks in a particular ROM.  I generally keep the latest backup of the ROM(s) I’m using on the card and move the older ones to my PC.  This has worked well for me in the past.

Recently I needed to restore from backup and found the last month’s backups of several ROMs would not restore:  checksum errors.  WTF?     During my troubleshooting I noticed that backups moved with USB were ok and backups by FTP were corrupted about half the time.  Hmmm.

Could filezilla be confused and doing ASCII line-end changes or something?  I went in to make sure it wasn’t set up to xfer as ASCII;  it was set to AUTO which should have been OK because none of the file patterns in the “automatic file type classification” dialog matched the filenames.

More testing.  More corruption. Wrote a quick/dirty script to re-hash the files after they were FTPed down to the PC, as my eyeballs were getting tired doing it manually:

# cmsum.sh
# checks the md5sums of backup files in specified directory

# check for arg
if [ “$1” == “” ]

then
echo “USAGE: cmsum.sh {dirname}”
exit 1
fi

cd $1

echo -n Generating cmsum.md5…
md5sum boot.img > cmsum.md5
echo -n .
md5sum cache.yaffs2.img >> cmsum.md5
echo -n .
md5sum data.yaffs2.img >> cmsum.md5
echo -n .
md5sum recovery.img >> cmsum.md5
echo -n .
md5sum sd-ext.ext4.tar >> cmsum.md5
echo -n .
md5sum system.yaffs2.img >> cmsum.md5
echo -n .
md5sum .android_secure.vfat.tar >> cmsum.md5
echo running diff…

diff cmsum.md5 nandroid.md5 && echo Backup OK

Soon the pattern emerged that it was .android_secure.vfat.tar that was being corrupted.  Back to filezilla’s config.  Oh, crap.

There it is.  Dotfiles (.whatever) were being treated as ASCII due to a default I’d overlooked.  Deselected that and the corruption stopped.  I think this setting overrides the forced BINARY mode setting above, although I don’t remember the order of events that closely.

Anyhow, you have been warned.  Spotcheck the hashes of some of your offloaded backups to make sure you’re not a drooling idjit like me.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s