High processor usage!

[KJake]

A couple things...I'm not totally sure of my date checking either :-)

I'll explain and then give a couple suggestions...
stat returns all sorts of variables as you can see, but most importantly, $atime, $ctime, $mtime, which mean different things in Windows and Unix. Since I'm being a little lazy I'm assuming Windows is a=Access, c=Creation, m=Modification times. These times are in a funky format that I'm also being lazy trying to figure out.

So, the way I figured it out was to take the Access time from the real Wiz.bin because it would be the closest to today's date/time stamp then I compare to the Creation time of the files in the second stat. Based on playing around I appoximately calculated what a 2 week span should look like...so we're beta testing this :-)

So, here's my suggestions - don't add the 4th copy for Wiz.bin and leave the first stat alone and I noticed a 'dumb' thing I did that you can fix in your version. When you change the opendir(DIR, "..."), just do opendir(DIR,$sageback);
It works the same, and I should have used $sagepath in mine.

And because I feel like explaining more things :-)

if ($file =~ /Wiz[0-9]{8}/ <-- this thing looks odd to a normal person.

In english: IF varible($) file matches(=~) something of the form(//) containing Wiz with exactly 8({8}) digits ranging from 0 thru 9([0-9]) following.

$filename = $sagepath.$file; <-- This is concatenation

$date =~ s/\n//eg; <-- odd looking too, huh?

$date now equals the result of the expression s/\n//eg, meaning s=substitute things in here (/\n/) with this (//). I think g=global, and I don't remeber what e is and they're probably both useless. Example.

s/tom/bob/;

My name is tom.
becomes
My name is bob.
Case sensitive.

\n means new line, so what I'm doing is removing the new line that is hidden on the end of the datestamp output so when we tack the .bak or .bin back onto the file name we don't loose it.

I'll stop there so I don't bore anyone or make myself look dumb by not explaining something right. :-)

Have fun. Email/PM/Post the new script and I'll be glad to critique.

[justme]

Ok so having the opendir pointing to my $sageback suddirectory won't affect the first "stat" since that "stat" is explicitly declaring where the main wiz.bin is?

This was why I added a fourth copy. I was worried that having the opendir and first "stat" pointing to two different locations would cause problems. Also I was wrongly assuming you were using the data modified attribute to calculate the time difference. I knew that the date modified attrib was not affected by a copy command. But since your using the date accessed attribute the date would always be the same day/time the script was run.(Duh)That would never have worked, since a copy changes the access attrib. So my copy does nothing to help protect the calculations.

So, the way I figured it out was to take the Access time from the real Wiz.bin

Shouldn't we use the date modified attrib instead? This would point to the last time SageTV made a change to the Wiz.bin file. As it stands if a user didn't use SageTV for a week(unlikely) we would keep making backups of the same wiz.bin file and be deleting other older backups that could be of use in a recovery. Or is this just an unavoidable consequence of the method used the calculate the date difference. Of course this doesn't even affect most people since they run Sage 24/7.

Thanks for the explanation of the format the date code. It made sense to me. I didn't mean to turn you into a perl tutor.

[KJake]

Correct about the stat thing.

Yes, I thought of all of those same things last night :-) I originally was going to approach it by getting the current time stamp and compare it to the stripped down timestamp sections from the files, but then you run into calculating the date properly when you start a new month, and a whole bunch of date issues, so I thought the stat method of doing things was the lesser evil.

I looked at my code again, and I am using the modification time after all, good catch.

I am wondering, however if we want to add some code to guard against this problem you mention. You could do a simple test to see if the previous backup file (you'd have to find the latest) differs from the current file in the Sage directory. This would keep the backup program from making useless backups, and if you change some test cases around you could decide that if no backup was done, not to check for files older than 2 weeks, just to be safe. That way the backups are kept on the rotating schedule so long as the user is using sage.

Since you're so eager to learn, I'll let you takle that little task. Just shoot a message for help...and have fun while doing it! :-)

[justme]

OK,
I'll make the original modifications we talked about tonight. I should be able to do that fine thanks to all your help. Besides perl will give me an error if I really mess the format up. As for our lastest idea I will try to do that as well. Though probably not tonight, I need to let some of this sink in.

I think I'll perform the check for changes you mentioned and then handle the date issue in another way. If there is a way to find the newest file then the same technique(code/command) could be used to find the oldest. So I'll check for change in wiz.bin against the newest backup wiz. If there has been change I'll make a datenamed copy and then I'll delete the oldest copies if there are say more than 14.

This way I should be able to reuse the logic I used to find the most recent copy to find the oldest copy. All I'll need then is a way to count how many files of a certian .ext are in the subdir. If it's over 14 I'll delete the oldest til it's less than or equal to 14. This method should avoid all the messy date calculations. I don't what to get into those date calculation issues either. Of course I'll need to either prime the subdir(by manually making a backup wiz) or add logic to account for no backup wiz the first time the script runs.

Really I can't thank you enough for both the perl script and the pushes in the right directions. If I can ever help you in any way just PM.

[justme]

Hi KJake,

I made the original set of changes you and I talked about. I have attached the perl script. I had to zip it to attach it. If you could look at it I would appreciate it. It seems fine to me.
I made a few changes:
I added some comments
I used "chop" on the date
I used your concatenation example to modify the first "stat" to use $sagepath

I am also sending you a PM with my email address. If you aren't too busy I would appreciate you telling me if I really messed the script up. If it's fine then in a day or two I may try the more elaborate version we discussed in our last two messages.

[KJake]

Everything looks fine, this will put the backups into their own directory, and chop is a better, more correct way of removing a newline char.

I have an idea, this might be better for the 2 week portion.

In the current foreach:

Put each file type in its own array. @bin @bak @sage or something.
@bin = sort @bin;
if ($#bin > 14) { unlink($sagebackup.$bin[0]}; }

That should remove the oldest file. I'm not positive because, I'm sure how that sort function works. There is a way to specify numeric ascending or decending but I don't remember off the top of my head. $#bin is the number of items or length of the array, and you can access items of an array like $bin[index], but to manipulate and to use an array, it is @bin.

Do you get what I'm going after here?

[justme]

Thanks for looking over the script. I now have it running, and it performs as expected so far.

I'm fairly sure of what you mean. I too was thinking of that maybe an array* would be a good way to handle the three files, but was afraid it could get out of hand. Now, from your example I don't think it would be too bad. I'll check out the format and functions of the sort command. I'll also look into how perl addresses and manipulates arrays.

I found a neat little site on the basics of perl. That's how I found out about the chop command. The only downside is that most of the examples are geared toward webpage management. This adds another layer of complexity I'm not used to, so I sometimes lose the example's concept, since I don't really know webpage management. I'm looking for another good example based tutorial, since I can more easily learn by modifying existing code. But I think this site's tutorials will work for now.

*I have the math exeperience("Calc I" and "Discrete Mathmatics") to understand arrays. It's the programming experience I'm working on.

Thanks again.

PS:I guess I've finally decided to learn a programming language. I should have figured it would be perl. A webfriend at another forum suggested it about a year ago. The funny thing is he(jason531) just joined this forum recently. It's almost like some kind of grand perl consipiracy.

[KJake]

Hmm, well if you want to use math, then you could continue using stat.
http://www.rocketaware.com/perl/perlfunc/stat.htm
Here's the details on how it works.