RE: [ID 20000114.001] Perl rename function can delete files

["Moss, Jeff" <jmoss@huffmancorp.com>]

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

---

Follow-Ups from:

Jan Dubois <jand@ActiveState.com>

---

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

---