Try this...
Code:
# Using head instead of cat to only try 20 while testing
head -20 files_to_del.txt | while read fn; do [b]ls ${fn}[/b]; done
If the file exists, it will just print its name. If the file isn't there where you expect it, it will say "[tt]ls: cannot access PXPROD_bqsj2c03_77_1: no such file or directory[/tt]". Or whatever each filename is. This is just to see if they are there.
Have you done a few spot checks to make sure the files in your "[tt]files_to_del.txt[/tt]" file are really there? Pick a couple filenames and grep the file for them. Your file could have become out of sync with what's actually in the directory. It may look correct with a quick glance, but it could be off enough to miss them all.
Do you have permission to delete the files. You will not only need permission on the file itself, but you will also need 'w' amd 'x' on the directory they are in (it needs to be updated that the file is gone). If it's your current default directory, then look at the perms for the directory '.' (that's one dot).
Also, where did the "[tt]files_to_del.txt[/tt]" originate? If it came from a Windows system, you probably have a carriage-return/line-feed pair ending each line. This always messes up things like this. Look for a utility called "[tt]dos2unix[/tt]", or something like that. That will "fix" a Windows file.
Also, the files could have invisible characters in their names. Try adding a '[tt]-b[/tt]' switch to an '[tt]ls[/tt]' to see any non-printable characters in the names.
Lastly, if you know you're in the right directory, and you've checked all those things, the server is haunted. Burn it. Then take the remains and bury in among the roots of a banyan tree under a full moon. It's best to just cut your losses and move on in cases like this.