File Association Hiccups

We're on TS 7.2.0.0.0

We have a custom script that builds an html page with hyperlinks to files stored in TS. Our script goes out to this directory within TS and 'scans' all of our content (files) for a certain filename numbering convention, and then pulls the matches into an array and formats a url on the html for each one of the individual matches. (Example...we have a form that is a different variation for each one of the 50 states.) They are all either .pdf or .doc. When the script 'finds' the first match, it reads in the extension. In this example, it knows it's a pdf, so it writes the links as xxxx.pdf. (When it's time for our script to create the html page, it creates hyperlinks to all of the files it has 'found' using the .pdf file extension.)

We're now seeing intermittent instances of the script creating the hyperlinks as other file types, e.g., .doc/.xlsx...it's very strange. There are no other files in the scanned directory with the same base filename (but with other file type extensions).

I've had our TS administor verify that nothing has changed in the IIS file association configuration(s) since we upgraded to 7.2 a few months ago.

Any ideas?

We haven't made any changes to the custom script. That has been static for a few years. I'm wondering if there is something 'new' with the properties in the pdf files we're using that's causing this, and not something within TS. Shouldn't really matter if that's the case, because we're just looking for the .pdf extension...

Thanks for your time.

Find more posts tagged with

Comments

nipper

This is puzzling. It is custom code so highly likely that it is in the code. That being said, if this worked flawlessly with 6.7.2 and fails now, something is funky.

Can you share the code ? If you can reproduce/isolate the problem, it should not be to hard to fix.

There is nothing systemic in 7.2 that should cause this. It has to be a stupid difference and normal debugging should take care of it.

MikeLima

This is puzzling. It is custom code so highly likely that it is in the code. That being said, if this worked flawlessly with 6.7.2 and fails now, something is funky.

Can you share the code ? If you can reproduce/isolate the problem, it should not be to hard to fix.

There is nothing systemic in 7.2 that should cause this. It has to be a stupid difference and normal debugging should take care of it.

Code attached. I'm a Business Consultant by trade, so I only know enough of what our code does at a high level to make me dangerous. Thanks for taking the time to review!

Edit: Also attached a log file that is created when descriptionpage.tpl is kicked off. It shows the first file "found" as 90241050pdf, so I'm flustered how the script is creating the html with links to 90241050.doc!

var.JPG

nipper

This code is a mess and will take a lot of time to debug.

That being said you have a bunch of debug statements in there and you should uncomment them. Then run for a while and get the data when it fails.

I hope you have someone on site that knows Perl.

Andy

example4ContionnalPct.rptdesign

Adam Stoller

As nipper said, the code is not very well written.
I don't intend to fully debug it - but I will point out a couple of bad pieces of code with suggested alternatives:

opendir(DIR, "$docs_dir") || warn "Unable to read directory; $docs_dir ($!)\n";
@files = readdir(DIR);
closedir(DIR);

Instead, since you apparently don't deal with directories in your loops over the contents of @files, modify the above to be something like:

opendir(DIR, "$docs_dir") || warn "Unable to read directory; $docs_dir ($!)\n";
@files = grep { !-d "$docs_dir/$_" } readdir(DIR);
closedir(DIR);

That way you shouldn't need to check for "." and ".." in your later loops.

Then:

foreach $file (@files) {
    next if ($file eq "."); 
    next if ($file eq "..");
    my $filefif = $file;
    $filefif =~ s|(.*)\.\w\w\w|$1|;
    $file_ext_fif = $file;
    $file_ext_fif =~ s|.*\.(\w\w\w)|$1|;
    ...
}

Besides getting rid of the first two lines, your handling of separating the base name from the extension is highly questionable. For one thing you don't anchor the end of the regex so you're not limiting yourself to a three-character extension which the code would otherwise seem to suggest, and then there's the question of whether you should do so - consider that while you might have extensions like: