Command of the Day: COPYFILE()

[Walt Decker]

COPYFILE() does not exist.   How can it be created?

[xxgeek]

If your program is to copy a file or 2 then opening the file for input and another for file for output would be the way to go, but if your program copies quite a few files then creating a function would be best.

eg:
open "C:\My Files\FileToBeCopied.ext" for input as #1
open "d:\My BackedUpFiles\FileToBeCopied.ext" as #2
print #2, input$(#1, lof(#1));
close #2 : close #1
Keep in mind that if file #2 already exists, it will be overwritten.
So code according to your needs.
And if the file #1 doesn't exist there will be an error.
So check for it first.

You can also rename the file as you copy it.
eg:
open "C:\My Files\FileToBeCopied.ext" for input as #1
open "d:\My BackedUpFiles\FileToBeCopied.ext.bak" as #2
print #2, input$(#1, lof(#1));
close #2 : close #1

For multiple file copying use a function with above code.

eg:

Function copyFile(SourceFile$, DestFile$)
open SourceFile$ for input as #1
open DestFile$ as #2
 print #2, input$(#1, lof(#1));
 close #2 : close #1

Then to use the function to copy any file to any destination (within the rights of the user)
eg:

a = copyFile("C:\My Files\FileToBeCopied.ext", "d:\My BackedUpFiles\FileToBeCopied.ext.bak")

or you can declare the pathStrings as variables and use the variable
like so:
eg:

FileToBeCopied$ ="C:\My Files\FileToBeCopied.ext"
MyBackup$ = "d:\My BackedUpFiles\FileToBeCopied.ext.bak"

a = copyFile(FileToBeCopied$, MyBackup$)

'other code goes here along with an end statement

Function copyFile(SourceFile$, DestFile$)
open SourceFile$ for input as #1
open DestFile$ as #2 for output as #2
 print #2, input$(#1, lof(#1));
 close #2 : close #1
end function

[Walt Decker]

Your function will generate a compile time error. No END FUNCTION statement.
'
Function copyFile(SourceFile$, DestFile$)
open SourceFile$ for input as #1
open DestFile$ as #2
 print #2, input$(#1, lof(#1));
 close #2 : close #1
END FUNCTION
'

Will it work with all LB file types?
Can it be made more generic?

[tsh73]

Err..
open DestFile$ as #2 does not work either.
You really need to say for what you opening the file - INPUT OUTPUT APPEND or BINARY
so
open DestFile$ for output as #2

Also

Will it work with all LB file types?

is there such a thing as "LB file type" ?

I pretty sure it will work on _any_ file
(if it fits to LB memory that is)

[xxgeek]

oops!
Fixed

More Generic?

You mean like this?

source$ ="C:\My Files\FileToBeCopied.ext"
Dest$ = "d:\My BackedUpFiles\FileToBeCopied.ext.bak"

a = copyFile(source$, Dest$)

'other code goes here along with an end statement

Function copyFile(SourceFile$, DestFile$)
open SourceFile$ for input as #1
open DestFile$ as #2 for output as #2
 print #2, input$(#1, lof(#1));
 close #2 : close #1
end function

[Walt Decker]

is there such a thing as "LB file type" ?

Sure. Most BASIC languages define at least 3, sequential, random and binary. Other languages do not and leave it up to the programmer how the data is to be written.

More Generic?

No. More like this:
'
FUNCTION FN.COPYFILE(Source$, Dest$)

NumBytes = 0
RetVal   = 0

F1$ = "#Opn1"
F2$ = "#Opn2"

NumBytes = FN.OpenFile(Source$, F1$)
RetVal = FN.OpenFile(Dest$, F2$) '<--- repaired errors

PRINT #F2$, input$(#F1$, NumBytes)
RetVal = FN.CloseFile(F1$)
NumBytes = FN.CloseFile$(F2$) '<--- repaied error

FN.COPYFILE = NumBytes
END FUNCTION

'--------------------------
'--------------------------

FUNCTION FN.OpenFile(FileIn$, T$)

NumBytes = 0
OPEN FileIn$ FOR BINARY AS #1

NumBytes = LOF(#1)
MAPHANDLE #1, T$
FN.OpenFile = NumBytes
END FUNCTION
'--------------------------
'--------------------------

FUNCTION FN.CloseFile(T$)

NumBytes = 0
NumBytes = LOF(#T$)

CLOSE #T$

FN.CloseFile = NumBytes
END FUNCTION
'

Takes a little more code but you do not have to declare INPUT, OUTPUT, or RANDOM and you can be assured that the file will be opened because 1) you are renaming the file open tag, and 2) all files are binary. Also, by checking the return bytes on close against the return bytes on open you can be reasonably certain that all the bytes were copied.

EDIT:  Repaired a couple of errors in the function and pointed out the repair.

[xxgeek]

Takes a little more code but you do not have to declare INPUT, OUTPUT, or RANDOM and you can be assured that the file will be opened because 1) you are renaming the file open tag, and 2) all files are binary. Also, by checking the return bytes on close against the return bytes on open you can be reasonably certain that all the bytes were copied.

Thanks for the function Walt.

I see no check for existence.
Is a check still needed, or does this function take care of ensuring it exists before proceeding?

btw - I have used my example in multiple programs without issue on any of the files being copied so far. File types include .dll .sll .bas .txt .exe .pdf etc.
Will there be issues at some point?
Should I really be using your method to avoid future issues, or will my method suffice (as long as checks are made for existence of course?)

[Walt Decker]

I see no check for existence.
Is a check still needed, or does this function take care of ensuring it exists before proceeding?

The check are there. Opening a file in binary mode always either creates the file or opens it if it exists regardless of LB file mode.
If the open function returns zero bytes the file
1) was just created by the open operation and has no data
2) the path does not exist. However, the open function I normally use does check for path existance to avoid crashes.

Should I really be using your method to avoid future issues, or will my method suffice (as long as checks are made for existence of course?

Use any method you like as long as it works. I see no issues. I have files that are nothing but functions of one kind or another and just plunk the appropriate file into my code. Saves a lot of typing and debugging.

[tsh73]

Opening a file in binary mode always either creates the file or opens it if it exists regardless of LB file mode.

I pretty sure after file is closed by LB, it does not differ from file created by any other means
So "LB file mode" does not exists in a file.
Only in programmer's head.

So you can open same file in any mode (it might not make sence *working* with file in different mode, but you indeed can do it).

[Walt Decker]

I pretty sure after file is closed by LB, it does not differ from file created by any other means
So "LB file mode" does not exists in a file.
Only in programmer's head.

So you can open same file in any mode (it might not make sence *working* with file in different mode, but you indeed can do it).

You are contradicting yourself. If the file mode(data layout) does not exist in the file, why would anyone have difficulty working with it using some other data layout?