Perl not deleting file content if file on server

[Markus Hänchen]

Hi,

using
open RESULTS, ">results.txt";
does not delete the contents of the file if the file sits on a server.
However, using print I can overwrite as many characters as I want. For
example, if the content of the file is 'Fred went home.', and I write
(via print) 'Carl' then only the first four characters get replaced
with rest remaining, i.e. the file will look now 'Carl went home.'. I
can also append to the file using:
open RESULTS, ">>results.txt";

If the file sits on C:\\, then using
open RESULTS, ">results.txt";
actually wipes the file and 'Fred went home.' turns into 'Carl' only.

Is this known and expected behaviour, and is there a way to force it to
wipe out the content of a file?

Running on a Windows 2000 machine using the latest PXPerl
(http://pxperl.com) installation, the 'server' actually being a shared
folder in VirtualPC (which Windows sees as a server).

Cheers

Markus

 

[Paul Lalli]

using
open RESULTS, ">results.txt";
does not delete the contents of the file if the file sits on a server.

This is non sensical. The fact that the machine the file resides on
happens to also be running one or more server programs has no causal
relationship to opening a file.

Please better define *what* you are doing. Are you attempting to open
a file remotely? If so, the code you've shown is clearly not your real
code.

Please post a SHORT but COMPLETE script that demonstrates the error you
are seeing.

However, using print I can overwrite as many characters as I want. For
example, if the content of the file is 'Fred went home.', and I write
(via print) 'Carl' then only the first four characters get replaced
with rest remaining, i.e. the file will look now 'Carl went home.'. I
can also append to the file using:
open RESULTS, ">>results.txt";

If the file sits on C:\\, then using
open RESULTS, ">results.txt";
actually wipes the file and 'Fred went home.' turns into 'Carl' only.

Is this known and expected behaviour, and is there a way to force it to
wipe out the content of a file?

Perhaps trunctate() will do what you want?
perldoc -f truncate

Paul Lalli

 

[Markus Hänchen]

Perhaps trunctate() will do what you want?

perldoc -f truncate

Paul Lalli

Thanks a lot, truncate does do the job.



And thanks for the other reply as well. Since I am working in Windows
(i.e. DOS) I cannot use 'cat' but I try to provide equivalent
information:

(Drive z is recognized by Windows as 'type: Network Drive', it actually
is a folder sitting on the harddrive of my Mac which is made available
to Windows.)

(First: results.txt does not exist yet)
z:\Work\results.txt
'results.txt' does not exist

(First script
z:\Work\notwiping1.pl
#! /usr/bin/perl

use strict;
use warnings;

open RESULTS, ">results.txt";
print RESULTS "Fred went home.\t";
close RESULTS;

z:\Work\perl notwiping1.pl

z:\Work\results.txt
Fred went home.

(Second script
z:\Work\notwiping2.pl
#! /usr/bin/perl

use strict;
use warnings;

open RESULTS, ">results.txt";
print RESULTS "Carl";
close RESULTS;

z:\Work\perl notwiping2.pl

z:\Work\results.txt
Carl went home.


-------------
Now if I do exactly the same on
c:\running_perl\perl notwiping1.pl

c:\running_perl\results.txt
Fred went home.

(Second script
c:\running_perl\perl notwiping2.pl

z:\Work\results.txt
Carl

 

[Peter J. Holzer]

This is non sensical. The fact that the machine the file resides on
happens to also be running one or more server programs has no causal
relationship to opening a file.

Markus' description makes it likely that by "sits on a server" he meant
"is on a filesystem accessed via some network filesystem protocol,
probably SMB". In this case, the difference between a local filesystem
and a remote filesystem can cause quite different behaviour. In fact I
have seen exactly this behaviour several years ago on an EMC² NAS
device. The SMB protocol has several methods for opening a file (in
fact, it has several methods for just about everything - whoever's
responsible for it must be a great fan of TMTOWTDI), and one of them
wasn't correctly implemented - the equivalent of the O_TRUNC flag was
ignored. EMC² fixed the bug, of course.

hp