Perl rename function can delete files #1037

p5pRT · 2000-01-14T10:27:50Z

Migrated from rt.perl.org#1988 (status was 'resolved')

Searchable as RT1988$

p5pRT · 2000-01-14T10:27:50Z

From jmoss@huffmancorp.com

There is a problem with the "rename" function in the latest builds
of ActiveState Perl, dating at least back to build 515. The system
I'm running is WinNT 4.0 on Intel with Perl 5.005_03 build 521.

If you use "rename" to change the case of a file name on a network
volume the file just gets deleted.

The reason is that code has been added to the "win32_rename" function in
the file "win32.c" to use the "MoveFileEx" function when on WinNT. The
"MoveFileEx" function is being called with the "MOVEFILE_COPY_ALLOWED"
mask set, and that is incorrect most of the time.

MOVEFILE_COPY_ALLOWED means: (quoting the MSDN documentation)

"If the file is to be moved to a different volume, the function simulates
the move by using the CopyFile and DeleteFile functions."

Therefore if you're just changing the case of the file name the file
gets copied to itself then deleted. I should note that for some reason
this does not happen on local volumes.

I will be happy to add code to only use this flag when renaming across
volumes if you can tell me where to send it.

Jeff Moss

Perl Info



Site configuration information for perl 5.00503:

Summary of my perl5 (5.0 patchlevel 5 subversion 03) configuration:
  Platform:
    osname=MSWin32, osvers=4.0, archname=MSWin32-x86-object
    uname=''
    hint=recommended, useposix=true, d_sigaction=undef
    usethreads=undef useperlio=undef d_sfio=undef
  Compiler:
    cc='cl.exe', optimize='-Od -MD -DNDEBUG -TP -GX', gccversion=
    cppflags='-DWIN32'
    ccflags ='-Od -MD -DNDEBUG -TP -GX -DWIN32 -D_CONSOLE -DNO_STRICT
-DHAVE_DES_FCRYPT -DPERL_OBJECT'
    stdchar='char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
    alignbytes=8, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='link', ldflags ='-nologo -nodefaultlib -release
-libpath:"C:\Perl\lib\CORE"  -machine:x86'
    libpth="C:\Perl\lib\CORE" "c:\program files\devstudio\vc\lib"
"c:\program files\devstudio\vc\mfc\lib" "%lib%" 
    libs= oldnames.lib kernel32.lib user32.lib gdi32.lib  winspool.lib
comdlg32.lib advapi32.lib shell32.lib ole32.lib  oleaut32.lib netapi32.lib
uuid.lib wsock32.lib mpr.lib winmm.lib  version.lib odbc32.lib odbccp32.lib
PerlCRT.lib
    libc=C:\Perl\lib\CORE\PerlCRT.lib, so=dll, useshrplib=yes,
libperl=perlcore.lib
  Dynamic Linking:
    dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -release
-libpath:"C:\Perl\lib\CORE"  -machine:x86'

Locally applied patches:
    ACTIVEPERL_LOCAL_PATCHES_ENTRY


@INC for perl 5.00503:
    C:/Perl/lib
    C:/Perl/site/lib
    .


Environment for perl 5.00503:
    HOME (unset)
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
 
PATH=C:\Perl\bin;C:\WINNT\system32;C:\WINNT;Y:\DLC;Y:\DLC\bin;C:\PROGRA~1\UL
TRAEDT;c:\data\util;c:\program files\devstudio\sharedide\bin\ide;c:\program
files\devstudio\sharedide\bin;c:\program
files\devstudio\vc\bin;y:\syteline;c:\watcom\binnt;c:\watcom\binw
    PERL5OPT=-MWild
    PERLTOOLS=c:\data\util\FortranTools\
    PERL_BADLANG (unset)
    SHELL (unset)

p5pRT · 2000-01-14T10:51:13Z

From @gsar

On Fri, 14 Jan 2000 13:30:47 EST, "Moss, Jeff" wrote:

If you use "rename" to change the case of a file name on a network
volume the file just gets deleted.

The reason is that code has been added to the "win32_rename" function in
the file "win32.c" to use the "MoveFileEx" function when on WinNT. The
"MoveFileEx" function is being called with the "MOVEFILE_COPY_ALLOWED"
mask set, and that is incorrect most of the time.

MOVEFILE_COPY_ALLOWED means: (quoting the MSDN documentation)

"If the file is to be moved to a different volume, the function simulates
the move by using the CopyFile and DeleteFile functions."

Therefore if you're just changing the case of the file name the file
gets copied to itself then deleted. I should note that for some reason
this does not happen on local volumes.

I will be happy to add code to only use this flag when renaming across
volumes if you can tell me where to send it.

Thanks for the diagnosis. Diffs may be sent using perlbug to the same
address.

Sarathy
gsar@ActiveState.com

p5pRT · 2000-01-18T02:59:21Z

From [Unknown Contact. See original ticket]

At 13:30 -0500 2000-01-14, Moss, Jeff wrote:

There is a problem with the "rename" function in the latest builds
of ActiveState Perl, dating at least back to build 515. The system
I'm running is WinNT 4.0 on Intel with Perl 5.005_03 build 521.

If you use "rename" to change the case of a file name on a network
volume the file just gets deleted.

Ouch! That's serious. I don't run perl on Win* systems myself. Can
someone else on the list confirm this behaviour with stable and
development perls?

I will be happy to add code to only use this flag when renaming across
volumes if you can tell me where to send it.

As a reply to this mail. That'll make it hit the perl5-porters list
and flag it as related to the initial bug report. If you can format
your changes as a UNIX-style patch, so much the better. But, if you
can't, send whole modified files either as attachments or (if you
only touch one file) in the body of the mail.

Thanks.

--
Dominic Dunlop

p5pRT · 2000-01-18T05:23:07Z

From [Unknown Contact. See original ticket]

There is a problem with the "rename" function in the latest builds
of ActiveState Perl, dating at least back to build 515. The system
I'm running is WinNT 4.0 on Intel with Perl 5.005_03 build 521.

If you use "rename" to change the case of a file name on a network
volume the file just gets deleted.

Ouch! That's serious. I don't run perl on Win* systems myself. Can
someone else on the list confirm this behaviour with stable and
development perls?

I do confirm this behaviour for 5.005_63 and ActiveState perl 5.005_03,
build 522
(file gets deleted) and confirm that *no* such effect for 5.004_02.

Good luck,
Vadim

p5pRT · 2000-01-18T10:08:12Z

From [Unknown Contact. See original ticket]

Original tracking record and reply is as follows:
Re: [ID 19991018.001] Perl function "rename oldname, newname" eats
network files

If you think about it. It has to be a M$ bug. Why should perl care how many
renames it has done or how many files there are in a directory.
I've recently had to rewrite some ftp code that I had been running. The file
was transfered under a temproary name and then renamed to the final name.
But depending upon the current configuration of stars, a random number of
files would not show up in the remote machine.
So using that tried and true debuggin mechanism I tried some voodoo
programming and altered the algorithm to avoid the rename. Lo and behold no
complaints in two months.
Isn't voodoo programming fantastic.
<chaim>
>>>>> "DA-" == D'ANDREA Andy -NUCLEAR
<andy.d.andrea@ontariopowergeneration.com
<mailto:andy.d.andrea@ontariopowergeneration.com> > writes:

DA-> This is a bug report for perl from
andy.d.andrea@ontariopowergeneration.com
<mailto:andy.d.andrea@ontariopowergeneration.com> , DA-> generated with the
help of perlbug 1.26 running under perl 5.00503.
DA-> The "rename oldname, newname" function was being used to rename all
files DA-> in a directory that were named in lowercase or a lower/uppercase
mix to all DA-> uppercase.
DA-> The following code stops when the rename fails the first time. This
code is DA-> being run on a networked NT 4 system. The problem occurs when
running the DA-> script on a network directory containing about 20 files
having lower case DA-> character in their names. It doesn't seem to be a
problem if working on a DA-> local hard disk.
DA-> The file being worked on when rename fails is deleted from the
filesystem!
DA-> Please let me know if fixed patch exists.

--
Chaim Frenkel Nonlinear Knowledge,
Inc.
chaimf@pobox.com <mailto:chaimf@pobox.com>
+1-718-236-0183

----------
From: Moss, Jeff [SMTP:jmoss@huffmancorp.com]
Sent: Tuesday, January 18, 2000 11:40 AM
To: D'ANDREA Andy -NUCLEAR
Subject: FW: [ID 20000114.001] Perl rename function can delete
files

Could you please reply to this message and give them your
original tracking number.

Jeff Moss

-----Original Message-----
From: Dominic Dunlop [mailto:domo@computer.org]
Sent: Tuesday, January 18, 2000 5:17 AM
To: Moss, Jeff
Cc: perl5-porters@perl.org
Subject: Re: [ID 20000114.001] Perl rename function can delete files

At 13:30 -0500 2000-01-14, Moss, Jeff wrote:
>There is a problem with the "rename" function in the latest builds
>of ActiveState Perl, dating at least back to build 515. The system
>I'm running is WinNT 4.0 on Intel with Perl 5.005_03 build 521.
>
>If you use "rename" to change the case of a file name on a network
>volume the file just gets deleted.

Ouch! That's serious. I don't run perl on Win* systems myself.
Can
someone else on the list confirm this behaviour with stable and
development perls?

>I will be happy to add code to only use this flag when renaming
across
>volumes if you can tell me where to send it.

As a reply to this mail. That'll make it hit the perl5-porters list

and flag it as related to the initial bug report. If you can format

your changes as a UNIX-style patch, so much the better. But, if you

can't, send whole modified files either as attachments or (if you
only touch one file) in the body of the mail.

Thanks.

--
Dominic Dunlop

p5pRT · 2000-01-19T16:40:18Z

From @jandubois

On Tue, 18 Jan 2000 11:17:28 +0100, Dominic Dunlop <domo@computer.org>
wrote:

At 13:30 -0500 2000-01-14, Moss, Jeff wrote:

There is a problem with the "rename" function in the latest builds
of ActiveState Perl, dating at least back to build 515. The system
I'm running is WinNT 4.0 on Intel with Perl 5.005_03 build 521.

If you use "rename" to change the case of a file name on a network
volume the file just gets deleted.

Ouch! That's serious. I don't run perl on Win* systems myself. Can
someone else on the list confirm this behaviour with stable and
development perls?

It is a bug in the underlying Win32 API call:

http://support.microsoft.com/support/kb/articles/q193/0/70.asp

I will be happy to add code to only use this flag when renaming across
volumes if you can tell me where to send it.

As a reply to this mail. That'll make it hit the perl5-porters list
and flag it as related to the initial bug report. If you can format
your changes as a UNIX-style patch, so much the better. But, if you
can't, send whole modified files either as attachments or (if you
only touch one file) in the body of the mail.

I haven't seen any patch yet.

I'll add code to check for caseinsensitive equality and do the temporary
filename workaround if no one else proposes a better solution. This will
not cover all cases though: If someone uses an UNC file name on one side
and a path relative to a mapped drive letter on the other side then the
equality cannot be detected. But I guess the simple check will catch over
90% of the actual cases.

-Jan

p5pRT · 2000-01-20T05:06:49Z

From [Unknown Contact. See original ticket]

Sorry I haven't had a chance to post a patch. I've had
to work on my real job a lot the past few days, and will
for the rest of this week.

I really hadn't thought of this as a Microsoft bug. The
MFC doc says the MOVEFILE_COPY_ALLOWED mask uses CopyFile
then DeleteFile. So I guess it does what I expected it to.

I wasn't going to use the MOVEFILE_COPY_ALLOWED mask
unless I was sure the new file name was on a different
volume than the old file.

I hadn't thought about UNC paths.

Jeff Moss
JMoss@HuffmanCorp.com

-----Original Message-----
From: Jan Dubois [mailto:jand@ActiveState.com]
Sent: Wednesday, January 19, 2000 7:44 PM
To: Dominic Dunlop
Cc: Moss, Jeff; perl5-porters@perl.org
Subject: Re: [ID 20000114.001] Perl rename function can delete files

On Tue, 18 Jan 2000 11:17:28 +0100, Dominic Dunlop <domo@computer.org>
wrote:

At 13:30 -0500 2000-01-14, Moss, Jeff wrote:

There is a problem with the "rename" function in the latest builds
of ActiveState Perl, dating at least back to build 515. The system
I'm running is WinNT 4.0 on Intel with Perl 5.005_03 build 521.

If you use "rename" to change the case of a file name on a network
volume the file just gets deleted.

Ouch! That's serious. I don't run perl on Win* systems myself. Can
someone else on the list confirm this behaviour with stable and
development perls?

It is a bug in the underlying Win32 API call:

http://support.microsoft.com/support/kb/articles/q193/0/70.asp

I will be happy to add code to only use this flag when renaming across
volumes if you can tell me where to send it.

As a reply to this mail. That'll make it hit the perl5-porters list
and flag it as related to the initial bug report. If you can format
your changes as a UNIX-style patch, so much the better. But, if you
can't, send whole modified files either as attachments or (if you
only touch one file) in the body of the mail.

I haven't seen any patch yet.

I'll add code to check for caseinsensitive equality and do the temporary
filename workaround if no one else proposes a better solution. This will
not cover all cases though: If someone uses an UNC file name on one side
and a path relative to a mapped drive letter on the other side then the
equality cannot be detected. But I guess the simple check will catch over
90% of the actual cases.

-Jan

p5pRT · 2000-01-20T11:07:04Z

From @jandubois

On Thu, 20 Jan 2000 08:09:58 -0500, "Moss, Jeff" <jmoss@huffmancorp.com>
wrote:

I really hadn't thought of this as a Microsoft bug. The
MFC doc says the MOVEFILE_COPY_ALLOWED mask uses CopyFile
then DeleteFile. So I guess it does what I expected it to.

It only uses CopyFile when the source and destination are not on the same
volume.

I wasn't going to use the MOVEFILE_COPY_ALLOWED mask
unless I was sure the new file name was on a different
volume than the old file.

The problem isn't really the MOVEFILE_COPY_ALLOWED flag, but the
MOVEFILE_REPLACE_EXISTING one. We want to use this bit to get consistent
behavior with the rename() function on UNIX, which will also potentially
delete the target file before doing the rename.

I hadn't thought about UNC paths.

So it looks like a simple check for case insensitive equality is the best
we can do I guess.

-Jan

p5pRT · 2004-11-02T14:21:24Z

From @steve-m-hay

The fix proposed by Jan Dubois was applied to perl v5.5.640 (first
available in a stable release as v5.6.0) as change #4885, so the bug has
long since been resolved.

p5pRT · 2004-11-02T14:21:27Z

@steve-m-hay - Status changed from 'open' to 'resolved'

p5pRT closed this as completed Nov 2, 2004

p5pRT added Severity Medium distro-mswin32 type-library labels Oct 18, 2019

p5pRT mentioned this issue Oct 19, 2019

Program terminated with signal 11, Segmentation fault. #12469

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Perl rename function can delete files #1037

Perl rename function can delete files #1037

p5pRT commented Jan 14, 2000

p5pRT commented Jan 14, 2000

p5pRT commented Jan 14, 2000

p5pRT commented Jan 18, 2000

p5pRT commented Jan 18, 2000

p5pRT commented Jan 18, 2000

p5pRT commented Jan 19, 2000

p5pRT commented Jan 20, 2000

p5pRT commented Jan 20, 2000

p5pRT commented Nov 2, 2004

p5pRT commented Nov 2, 2004

Perl rename function can delete files #1037

Perl rename function can delete files #1037

Comments

p5pRT commented Jan 14, 2000

p5pRT commented Jan 14, 2000

From jmoss@huffmancorp.com

p5pRT commented Jan 14, 2000

From @gsar

p5pRT commented Jan 18, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Jan 18, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Jan 18, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Jan 19, 2000

From @jandubois

p5pRT commented Jan 20, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Jan 20, 2000

From @jandubois

p5pRT commented Nov 2, 2004

From @steve-m-hay

p5pRT commented Nov 2, 2004