Comment 3 for bug 399694

That might work as well, if there is a chance to pass 'force' (-f) switch.
//Marek

On Fri, Jul 17, 2009 at 3:23 PM, LenZ <email address hidden> wrote:

> I wonder if instead of "/bin/mv" I could use the "move" function from
> File::Copy instead...
>
> ** Changed in: mylvmbackup
> Importance: Undecided => Medium
>
> ** Changed in: mylvmbackup
> Status: New => In Progress
>
> ** Changed in: mylvmbackup
> Milestone: None => 0.13
>
> ** Changed in: mylvmbackup
> Assignee: (unassigned) => LenZ (lenzgr)
>
> --
> Unpredictable result of do_backup_rsync procedure
> https://bugs.launchpad.net/bugs/399694
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in mylvmbackup - A tool for quickly creating backups of a MySQL
> server's data files: In Progress
>
> Bug description:
> We have tried to use the backup method 'rsync' to crete the backup copy.
> The goal to achieve was to get ONE copy of the database updated every time
> when mylvmbackup runs. After adjusting config options 'prefix','suffix' and
> leaving 'datefmt' option empty - the result was expected to be fine, but due
> to unpredictable behaviour of 'rename' (as perldoc explains its results may
> differ), there was the temporary directory left every time, without updating
> the target directory created first time. To fix this following change in the
> main program seems to be reasonable:
> if (run_command("create rsync archive", $command))
> {
> system("/bin/mv", "-f", "$destdirtmp", "$destdir") if ($destdirtmp ne
> $destdir);
> return 1;
> } else {
> return 0;
> }
> as this way we can force the update even though the target exists.
> Tested on: RHEL 4.6 (perl, v5.8.5 built for i386-linux-thread-multi) +
> mylvmbackup 0.12
>