Why FILECOPY raises ERR after overwrite

[Peter Noren]

FILECOPY will overwrite file as documented, but raises ERR=75, am I doing something wrong, or .. ?
Any help would be appreciated.

' FILECOPY raises error if DestFile exist (even if not read-only)
' To test example, create simple textfile c:\Temp\test_s.txt

' 1:st time executed, when sDestFile doesn't exist, everything goes OK
' 2:nd time executed when sDestFile exist
' , file is copied but ERR 75 Path/File ACCESS error is raised, why ?

$COMPILE EXE

FUNCTION WINMAIN (BYVAL CurInst AS LONG, _
BYVAL PrvInst AS LONG, _
CmdLine AS ASCIIZ PTR, _
BYVAL CmdShow AS LONG) EXPORT AS LONG
DIM sSourceFile AS STRING
DIM sDestFile AS STRING

ON ERROR GOTO WinMain_Err

sSourceFile = "c:\temp\test_s.txt"
sDestFile = "c:\temp\test_d.txt"

FILECOPY sSourceFile, sDestFile ' Copies sSourceFile but raises ERR=75 Path/File Access error
' if sDestFile exist
MSGBOX "FILECOPY was OK"

WinMain_Exit:
EXIT FUNCTION

WinMain_Err:
MSGBOX "Error code = " & STR$(ERRCLEAR)
RESUME WinMain_Exit
END FUNCTION

[Lance Edmonds]

Peter, I tested you code on my Win95a system, and it runs flawlessly (I copied "C:\AUTOEXEC.BAT" to "C:\AUTOEXEC.$$$" and repeated this over a dozen times... no errors occurred at all.

Are you sure the destination file was not open by another process when you tested the code? (or attributes were set for read-only, etc)

Lance
PowerBASIC Support

[Robert Lambach]

I can confirm Peter's message that filecopy will generate error 75 if the destination file already exists.
(using WinNT 4 SP5).

It's easy to get around by checking and killing the destination file before filecopying, or ignoring err 75 afterwards.

Robert

[Peter Noren]

No readonly file (only archive-bit set).
I have NT 4.0 too (sorry I didn't say that).

[Lance Edmonds]

Hmmm... I tested on Win95a. I'll ask R&D about this.

Lance
PowerBASIC Support

[DienyduToit]

Lance, you passed my error 75 query to R&D quite a long time ago. I am using PB/DLL 5.0
pending some sort of outcome. Maybe this new
error 75 problem uncovers someting ...

[Lance Edmonds]

Dieny, your issue is indeed in the hands of R&D. Whether it is related is something that only R&D can determine.

Lance
PowerBASIC Support

[Dave Navarro]

If you call the CopyFile() API call yourself telling it to overwrite, Windows will STILL return an error letting you know that a previous file was overwritten. Even though the copy operation is successful.

Therefore, Windows NT is returning an error back to PowerBASIC, which is in turn passing the error to you.

My suggestion is to ignore the error (call ERRCLEAR after the FileCopy operation).

--Dave

[Fred Buffington]

What will happen if the sub-folder does not exist prior to the
Filecopy statement ?
Example
FileCopy coid$+"\*.*" , "a:\"+coid$
where coid$ is a subdirectory / folder in the current folder.
Also, what if the floppy is unformatted ?

BTW (related subject) I tried using SHFormatDrive and got back
something like 4.29736E+9 or some such thing but nothing came up
that is, no format dialog. I was trying it as an option in a
menu program within a callback function. I saw something about
it wouldn't work if the desktop was the parent or something ?


------------------

[Tom Hanlin]

Eh, would it be so hard to just try it? But no, FILECOPY will not create a folder or format a disk for you. In these cases, it would return an error.

The issue of returning ERR=75 under NT when overwriting was due to an NT quirk that PB wasn't expecting. I believe that's been fixed.



------------------
Tom Hanlin
PowerBASIC Staff

[Lance Edmonds]

The FILECOPY statement does misreport an error under Windows NT in the current release of PowerBASIC, but R&D advise that this is to be addressed in the next update to the compiler (which is not yet ready for release).

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>