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.

1. Data Fork
2. Resource Fork
3. Permission
4. Time Stamp
5. BSD Flag
6. Finder Flag
7. Extended Attribute
8. Access Control List
9. Hardlink / Symlink / Alias
10. 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: [email protected]

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:

1. test for correctness
2. test for speed
3. test "copy" tools on multiple platforms
4. generate a HTML report

Mission right now:

1. 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.