Backup and restore should not be a lossy process. Do the right thing!
Test, test and test again.
This project is about evil torture-testing of backup tools/file utils on Mac OS X.
There are many things to consider when copying files.
- Data Fork
- Resource Fork
- Permission
- Time Stamp
- BSD Flag
- Finder Flag
- Extended Attribute
- Access Control List
- Hardlink / Symlink / Alias
- Special file types
Because there are so many things, it's really no surprise that it's causing problems for untested programs.
This program generates a HTML comparison table.
Requirements:
ruby 1.8.x or better.
rake
step 1:
prompt> rake
step 2:
type in your password when asked for password
step 3:
wait a few minutes
step 4:
the generated index.html file is opened in your browser
step 5:
Ignore this step if you want to run the test multiple times.
prompt> rake unmount
prompt> rm AnalyzeCopySource.sparseimage
remove AnalyzeCopySource.sparseimage? y
prompt> rm AnalyzeCopyDest.sparseimage
remove AnalyzeCopyDest.sparseimage? y
prompt>
Mail: neoneye@gmail.com
Twitter: https://twitter.com/neoneye
AnalyzeCopy - black box validation suite for copying files copyright 2009 - Simon Strandgaard
project name: AnalyzeCopy
project description: Torture-testing of File managers and programs that copy files.
see this article.
http://www.coredumps.de/doc/dump/zwicky/testdump.doc.html
Torture-testing Backup and Archive Programs: Things You Ought to Know But Probably Would Rather Not Elizabeth D. Zwicky SRI International Lisa V 1991
Inspirion comes from "Backup Bouncer" by "Nathaniel Gray", which I was very surprised to see. Its code is very elegant and some of the things going on is quite hard to do in Ruby.
I choose not to extend his code, since I cannot code BASH and would have a hard time figuring out how to add reporting features.
I already have a whitebox test suite.
Vision:
- test for correctness
- test for speed
- test "copy" tools on multiple platforms
- generate a HTML report
Mission right now:
- something that can test my own "copy" program for correctness.
IDEA: are tags preserved.
IDEA: html report should gather data from the result dirs, such as exitstatus, version, long version, is_ignored.
IDEA: 80_resource_fork, should be splitted into a 62_hardlink_resource test, so that tools that have no hardlink support also fails the resource fork test, despite having resource fork support.
IDEA: chgrp, chown
IDEA: Finder vs. attached comments
IDEA: is [NSWorkspace setIcon:forFile:options:] preserved.
IDEA: is order of ACL entries preserved.
IDEA: can we copy files with invalid ACL's so the ACL's are preserved.
IDEA: exercise mode_t for mkfifo
IDEA: exercise mode_t for mknod
IDEA: symlinks can have different timestamp than files
IDEA: xattr on symlinks
IDEA: test with difficult filenames, containing æøåÆØÅ etc.
IDEA: test with alias cycles
IDEA: more throughout testing of acls
IDEA: more throughout testing of locked files
IDEA: test setuid bit
IDEA: test setgid bit
IDEA: test chflags uappnd,uchg,nodump,opaque
IDEA: "no resource fork" != "has zero-size resource fork" exercise this
IDEA: copy dirs using Java's file api, what ever that is
IDEA: test HFS compression.. XATTR_SHOWCOMPRESSION with listxattr Inspiration here, in 75-hfs-compression.test and 76-hfs-compression_large.test http://www.bombich.com/groups/ccc/wiki/7ba51/
IDEA: test Apple's copyfile() function introduced in 10.5.
IDEA: currently the copy operations takes place between two DMGs. I'm considering changing it so there is a dedicated source.dmg per testee, this would make it more easy to see what tests has been disabled per testee.
We could create a read-only volume and copy data from it. After the copy operation is completed then remount the target volume as read-only... and then compare atime. However it's not worth it.
stat.ctime is updated when the inode is changed, by the filesystem. It's not a user settable property. So I don't think its possible to test it.
Does kFSCatInfoAttrMod and FSSetCatalogInfo() work - by John C. Daub Conclusion: no, it doesn't work. http://lists.apple.com/archives/carbon-dev/2007/Aug/msg00338.html
In the apple filesystem there are some files with inode 0, making them invisible for most tools. I don't think its possible to create files with inode 0 manually, so there is no way to test this.