search

Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
1.85k stars 527 forks source link

Perl rename function can delete files #1037

Closed p5pRT closed 19 years ago

p5pRT commented 24 years ago

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

Searchable as RT1988$

p5pRT commented 24 years ago

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 commented 24 years ago

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 commented 24 years ago

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 commented 24 years ago

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 commented 24 years ago

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. \   >>>>> "DA-" == D'ANDREA Andy -NUCLEAR \<andy.d.andrea@​ontariopowergeneration.com \mailto&#8203;:andy\.d\.andrea@&#8203;ontariopowergeneration\.com > writes​:

DA-> This is a bug report for perl from andy.d.andrea@​ontariopowergeneration.com \mailto&#8203;:andy\.d\.andrea@&#8203;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&#8203;:chaimf@&#8203;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 commented 24 years ago

From @jandubois

On Tue\, 18 Jan 2000 11​:17​:28 +0100\, Dominic Dunlop \domo@&#8203;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 commented 24 years ago

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@&#8203;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 commented 24 years ago

From @jandubois

On Thu\, 20 Jan 2000 08​:09​:58 -0500\, "Moss\, Jeff" \jmoss@&#8203;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 commented 19 years ago

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 commented 19 years ago

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