Yep, I can confirm problem (1)
I had three backups "aborted" last night
because they ended up running concurrently
due to slow network access to backup target share
I could not edit or restart or delete them
And because I am running unslung 1.11-beta
a soft or hard power-cycle did not clear the problem
So I telnet'd-in and grubbed around to find
/share/hdd/conf/etc/mnt/backup to discover
a directory named after each backup job and
a file called <backup>.pid which appeared to hold
the process ID of the /usr/sbin/backup (I think) process
I deleted the direcory + file and lo-and-behold
my backup jobs were editable again
I can *NOT* confirm the latter problem because
I'm running 3 x XP Pro and 1 x XP Home
(XP Home replaced Win98SE)
--- In firstname.lastname@example.org
, "seekinshome" <dlseek@h...>
> I have noticed two bugs with the backups:
> (1) if the backup fails for an "aborted" cause (e.g. "Maximum
> occur in job 'Basement G', job is aborted."). The job will not
> restart at the next scheduled time. Also, it cannot be edited,
> deleted, or manually restarted. The only way around this is to soft-
> power cycle the unit. Also, any new backups that use the same
> cannot be scheduled, and will not start if already scheduled.
> Anyone confirm?
> (2) Every once in a while, I get a strange error (or multiple) in
> otherwise normal backup. For example:
> "Error occurs in job 'Basement G', cannot access source
> pg'. " Even though it backed up all the new files on the drive,
> old file had a problem? I verified that the source file is present,
> and readable. The machine it is backing up is an old P3 1.4G
> Windows 98. Anyone else?
> I'm going to try to see what happens when the target PC is not
> powered up when the NSLU2 starts a scheduled backup to/from it.
> Hopefully it will not result in scenario #1 above.
> Does anyone from Linksys monitor this forum? Do they even care
> all these bugs we see?