in reply to Move files w/ commit-rollback mechanism?

copy the files instead of moving them. after copying compare file sizes to originals. if they match then delete local copies. if they don't match, re-try. be careful along the way if the destination is a different file system (e.g. it can become unavailable due to network failure, media failure etc.)...also file system full condition. Should just gracefully abort if the checking process fails...not much you can do if network goes down half-way through copying (just run it again later) EXCEPT if you know the destination system type you could waste lots of time and write your own self contained file installation script + files and copy this first to dest system before executing it (rsh?). mind you there are (non-perl) tools to do mirroring with commit/rollback already built in $$$
  • Comment on Re: Move files w/ commit-rollback mechanism?

Replies are listed 'Best First'.
Re: Re: Move files w/ commit-rollback mechanism?
by antirice (Priest) on Jun 12, 2003 at 05:17 UTC
    A better option may be an MD5 comparison of the contents of the files. If you're going to go through the trouble of creating a rollback mechanism for copying, you should at least verify that the files are exact matches (well, MD5 has a slight chance of creating the same hash for slightly differing inputs (i.e. the hard drive misreads and puts "I am a lonely man" instead of "I like to dress in women's clothing" and you get the same MD5 for both lines...which you don't, I checked), but the chances are somewhere in the realm of winning the lottery every drawing during a year and then dying from the combination of a shark attack and simultaneously getting struck by lightning, all while in Kansas...driving on the highway...in the middle of winter.... Actually, on second thought your chances may be worse than that...).

    antirice    
    The first rule of Perl club is - use Perl
    The
    ith rule of Perl club is - follow rule i - 1 for i > 1