LINK:
<A HREF="/cgi-bin/download.cgi?file=0111111.exe">Norton Definitions</A
+>

download.cgi:
#!/usr/bin/perl -wT
use strict;
use CGI;
use Fcntl qw|:flock|;

my $q = new CGI;
my ($file) = $q->param('file') =~ /^(\w+\.\w+)$/;
open (FILE, "/path/to/logs/$file.txt") or die("Can't open file: $!");
flock (FILE, LOCK_EX) or die("Can't lock file: $!");
my $count = <FILE> + 1;
open (FILE, ">/path/to/logs/$file.txt") or die("Can't open file for wr
+iting: $!");
print FILE $count;
close (FILE);
print "Location: http://site.com/downloads/$file\n\n";
[download]

Joshua

++ with reservations. You don't check to see if your match succeeded, and just let the script run into an invalid redirect or possibly the first of your dies. Giving the user an error page instead would be better. Also, when you reopen the counter file for writing, you lose the lock.

if(not defined $file) {
    print $some_error_page;
    exit;
}

sysopen FILE, "/path/to/logs/$file.txt", O_RDWR | O_CREAT
    or die "Can't open $file.txt: $!";
flock (FILE, LOCK_EX) or die("Can't lock $file.txt: $!");
my $count = <FILE> + 1;
seek FILE, 0, 0;
print FILE $count;
truncate FILE, tell FILE;
close FILE;
[download]

____________
Makeshifts last the longest.

You don't check to see if your match succeeded, and just let the script run into an invalid redirect or possibly the first of your dies.

Ah, that's why I said...

Obviously it wouldn't be great to use for production, but you get the idea.

I didn't include an error routine just for simplicity sake, though it may have been a good idea to.

Also, when you reopen the counter file for writing, you lose the lock.

Thanks for the point there.

Joshua

You forgot the most obvious case: four) Count the entries in the access_log file. That's why you have an access log in the first place.

Abigail

not directly with Perl(at least not easily) if you just do it with a vanilla hyperlink, but the chances are good that your ISP logs this info. Several sites I administer have Progams like Webaliser or Analog that create reports detailing how many times each link was requested on which date,etc.

If this is not possible, you could do a number of tricks that would accoplish this via a cgi script. Either have the user click a form submit button that calls a CGI to update a text file or DB then redirects to the files location, or use a hyperlink that calls a similar CGI like

<A HREF="../cgi-bin/servefile.cgi?file=0111111.exe">Norton Definitions
+</A>
[download]

• Provide a drop-file to count the times a user has hit the link, which you can do through any of the hundreds of 'web-counter' scripts out there.

  Note, this is subject to race attacks, if 10 people all want to download the file at the same time. You'll have to implement locking here.

  I've seen a few, but if you want to have a "You're the 'nth' person to download this file" type of interface, you want an ordinal script. If this is just for your own personal needs, that's not necessary. Stay away from the SSI versions, you want to roll this natively into your download script, likely.

• Increment the number of downloads through a database such as MySQL, which allows you to push the locking down to the database itself and substantially decrease the issue of race attacks. Basically you'd have a script like:

  http://www.you.com/download.pl?file="file0000.exe"

  With this you could also store the incoming IP, host, time, date, and referer of the person downloading it, if you wanted to keep that information (maybe good for charting, graphs, whatever)

• How about just parsing your web logs for the downloads instead? No issues with locking, no race attacks, and can be done hourly/nightly, etc. TMTOWTDI.

Thanks for all the replies. I have a Solaris 7 OS web server