unlink( $filename ) or die "Can't unlink $filename: $!";
[download]

This is the error i get. "Can't unlink MWALARM_ETH21611B_20070530-0615560 t get_alarmfiles.pl line 42, <FILEREAD> line 1." the script and the file are in two different place. do i need some additional code?

Oh yes, you need to specify the directory path:

unlink "$dirpath/$filename" or die "can't unlink $dirpath/$filename: $
+!";
[download]

And use the "$!" part since that will give you the file-system error.
"What should it profit a man, if he should win a flame war, yet lose his cool?"

• if your DIR handle was opened like this:

  my $path = "some/path"
  opendir( DIR, $path );
  [download]

  then your unlink has to be like this:

  unlink "$path/$filename";
  [download]

• if the directory indicated by $path has write permission turned off (for the user running the script at least), the script won't be able to delete (or add or rename) files in that directory.

Note that the permissions on the data file itself do not matter for "unlink" -- only the permissions on the directory containing the data file are important.

>Note that the permissions on the data file itself do not matter for "unlink" -- only the permissions on the directory containing the data file are important.

No, that's UNIX. On Windoze, to quote the MSDN:"To delete or rename a file, you must have either delete permission on the file or delete child permission in the parent directory".
An attempt to delete an open file will fail, and that is probably what is happening here.

This is probably Yet Another Good Reason to get rid of package-level filehandles in favour of lexical ones (even though we were not shown the code for Read_File, the use of package-level directory handles is a hint). It really strucks me that lexical filehandles were supported since 5.6 and yet the vast majority of the examples use non-lexical ones.

Flavio
perl -ple'$_=reverse' <<<ti.xittelop@oivalf

Don't fool yourself.

Is the file closed before you try to unlink it? Could another process have it open?

Could another process have it open?

If phimtau123 is on a *nixy system he could dig in `lsof`s output with (e)grep

Well, if he were on a UNIX system he wouldn't need to do that at all, because POSIX-compliant systems allow you to unlink files while they are being held open by another process, the process can continue reading/writing to the unlinked file but the file ceases to exist once the filehandle is closed. Also, greping lsof output for a filename is insanely wasteful, because it makes lsof pipe all the filenames of open files on the entire system to grep, which then throws most of them away. Instead, just do

lsof <filename>

All dogma is stupid.

use Paradoze;

my $dh = Opendir( 'drwx', $dir ); # use standard "paranoid" routines

while ( my $file = Readdir( 'rwx', $dh ) ) {
    my $path = "$dir/$file"; # do this anyway rather than expecting sa
+me directory!!
    FileTests( 'rwx', "$dir/$file" );
    # process the file
}

#... Paradoze.pm
package Paradoze; # paranoid utilities for windows corporate environme
+nts

sub Opendir {
    my ( $mask, $path ) = @_;
    FileTests( $mask, $path );
    opendir my $dh, $path or die "$! for path $path\n";
    $dh;
}

sub Readdir {
    my ( $mask, $dh ) = @_;
    # ...
}

sub FileTests {
    my ( $mask, $path ) = @_;
    for my $test ( split( '', $mask ) {
        eval "( -$test $path )" or FTFatal( $test, $path )";
    #...
}
[download]

Why doesn't perl run under the same user that calls it on Win32?
It does