COPY FILE in an Exe

[Steve Meyerson]

I created a backup method using COPY FILE within the main form (Stock.scx/sct) of the project.

It will not copy Stock.scx because it is open of course.

But when I build the exe, close the project, quit VFP, and run the exe, it copies other files, but still will not copy Stock.scx. Msg: "File in Use"

Everything's in the same folder but I would think running the backup in the exe should copy the scx anyway because Stock.scx is on the hard drive, but NOT open.

What am I not seeing? Anyone?

Steve

 

[Chriss Miller]

Have you closed VFP before running the EXE?

 

[igorsandler]

It is open, has to be. Check Task Manager. What is .scx anyway?

 

[Steve Meyerson]

Yes. I even checked Process & Services in the Task Manager for "Stocks.." or "MicrosoftVisua..". Nothing.

I even copy/pasted Stocks.scx to my backup folder while the exe was running. It copied ok. So that indicates it was not open.

I put it in a TRY/CATCH/ENDTRY. Still wouldnt copy but at least no message,

 

[Steve Meyerson]

Igor,

.scx is the extension of a form's file name. It's normally accompanied by a .sct file which has the same stem of the form's file name, but having .sct as its extension. I think the .sct file is like a 'memo' file. Both are really same structure as dbf/dbt files.

Clear? (as mud?)

 

[Chriss Miller]

I think it is because within the EXE the stock.scx will be referring to the running scx that's within the EXE.

I tried a reproduction of the problem and succeeded.
In a main.scx form I put a button that has this in its click:

Copy File another.scx To backup\another.scx
Copy File another.sct To backup\another.sct
Copy File some.scx to backup\some.scx
Copy File some.sct to backup\some.sct
Copy File main.scx to backup\main.scx
Copy File main.sct to backup\main.sct

Well, and as you can guess from that code I also have some.scx and another.scx in the project:

As you can see another.scx is excluded from the exe building, some.scx is included and main.scx is the main form. I made it modal, too and have no main.prg, for having these three different things.

After building, closing VFP and running the EXE I ge the same error for main.scx - "File is Open" in the line that copies the main.scx

And then I saw this in the folder:

It turns out that's still neither a new VFP bug nor a new Windows feature hindering VFP from working, it is due to a cloud storage I use with a sync feature for the whole tek-tips directory.

Anyway, I can also get the same error (FIle is open error, not the conflicted in the file name) when I wait for the sync to have finished and it's due to VFP referring to the main.scx within the EXE as it's searched and found first there.

As continuation of the experiment I did change some.scx and another.scx to have a label - the original scxes were just empty forms. I now did not rebuild the exe, so it's internal some.scx is still empty, the external some.scx has a label. there is no internal another.scx, only the external one. Now restarting the exe I still get the same error - didn't expect anything else.

But looking into the backup folder I see another.scx has the new label in it - it was overwritten from the changed original file. The some.scx that's included in the EXE without label can be found in the backup unchanged, so the internal some.scx is copied. The external some.scx was not copied over. Actually the some.scx and sct also were overwritten (safety messages popped up, whether I want to overwrite and I confirmed all 4 of them with yes). But the some.scx/sct were overwritten with the same old unlabeled some.scx form the files that still exist in the EXE as I didn't rebuilt it, the changed some.scx ws not copied.

So, in short: When using COPY FILE you don't necessarily copy files as found on disk, you also - and with priority if found inside the EXE - copy files from within the EXE.

I remembered this did not effect all file related commands and thought only FILETOSTR() could read from inside the exe, besides image files I told about in a not so recent thread are also taken from inside an exe from image controls picture properties. Anyway, it's obviously also effecting COPY FILE.

So to not copy from within your backup tool EXE you either use Windows API functions like MoveFileEx instead of VFPs COPY FILE or you ensure whatever you want to copy has no name as can also be found in your EXE.

 

[Steve Meyerson]

When using COPY FILE you don't necessarily copy files as found on disk, you also - and with priority if found inside the EXE - copy files from within the EXE.,

That explains it! I guess the file itself is actually inside the exe (or at least VFP treats it as such).

The example you created duplicates nearly exactly what I actually have, i.e. I have another scx (not the Main) which is not active during backup. It copies fine in the exe. I suppose if it were active it would also not copy.

I guess I had not run into this before. In any case, I don't distribute this app so I can back up the file manually or rely on my Acronis timed (once a day) backup. I figured it was just more convenient to do it in one click in my program.

Thanks Chris for your help. And also for your insight and expertise!

Steve

 

[Steve Meyerson]

Chris - FYI

The project files (pjx/pjt) copied fine in the exe!

Steve

 

[EinTerraner]

SCX and SCT-Files are actually same like a DBF and its FPT.
You can access those FORM-Files like any table

USE Stock.SCX alias CopyStock in 0 shared again
COPY TO <YourDestination>.SCX
USE IN SELECT CopyStock

 

[Steve Meyerson]

Ein,

Tried it in exe with all else closed. First line gives "File is in use." message.

Just realized you were probably addressing Igors post.

Steve

 

[Chriss Miller]

Chris - FYI

The project files (pjx/pjt) copied fine in the exe!

Steve

You closed VFP, didn't you? So? No surprise. The PJX/PJT files don't go into an EXE, they just organize all files within the project - but themselves.

Just like skin contains all tissue, organs and bones making up a human, but doesn't contain itself (unless you're picky and say the outer skin layers contain the inner ones - yes, of course).

PJX/PJT are even less than a physical container, they just maintain a list of project item files - not themselves, though. But you don't find the actual SCX/SCT in them, these form files are still separate files.

So you could also say the EXE becomes the PJX, just that the EXE is a real container, all the project itmes that are not set to excluded are actually put into the EXE file and are physically in it, the EXE becomes a physical container, like a ZIP, just that files are not compressed in it.

The inclusion or exclusion is set by sensible defaults. Forms, programs, all project itmes related to code are by default not excluded (so included), data files are excluded as normally you would like to modify data with your exe and couldn't, if it was included and thus would become static and read only. You can indeed also set dbfs included, but then could only read data from it.

Since the pjx/pjt are not themselves project items, you even don't have the chance of including them in a build into the EXE. they always remain separate files.

During a VFP session modifying a project the PJX/PJT files are open exclusive, that's when you can't copy them. But that's a totlaly different reason. Maybe you remeber having that difficulty. But it's erroring different, you don't just get "file is in use" error about that.

For files within an EXE you only get the "is in use" error. For the stock.scx as it's running and therefore in use. You can copy files from within an EXE that are not in use currently. You observed that yourself, as you said:

Steve Meyerson: "I have another scx (not the Main) which is not active during backup. It copies fine in the exe. I suppose if it were active it would also not copy."

So VFP treats included files as it would treat excluded files: Errors arise depending on their used or exclusively opened state. The problem that arises is not the containment within an EXE, the problem that arises is due to prioritizing finding files in an EXE first (even if you specify them with a path clearly outside the EXE) VFP looks at the included files of the EXE only, then, it overlooks outside files of the same name. Window API functions don't have that point of view and couldn't even look inside a VFP exe to see files in it, that's all just VFP internal.

PJX files are just a table, too, with those specific file extensions. There's one help topic "spilling the beans" that almost all VFP specific files for anything are just DBF tables. The topic describing the DBF file structure: "Table File Structure (.dbc, .dbf, .frx, .lbx, .mnx, .pjx, .scx, .vcx)" So all these are DBFs and their partner files (typically with t instead of x) are the FTP files of a DBF.

Each has their specific field schema and specific records for specific parts, and some of that is also described. For example, there are reports that print out how frx/frt report tables are structured and what data in their fileds means.

 

[Chriss Miller]

I don't distribute this app so I can back up the file manually or rely on my Acronis timed (once a day) backup. I figured it was just more convenient to do it in one click in my program.

That indicates you have this feature not for backup of data, but of the whole project itself. Why? Self backup is nothing with a big virtue, is it? You could make one backup exe that could make backups of all you projects, or even just a batch/cmd file doing that. Obviously best done when you closed VFP. Why the hassle of self backup?

There's even a good reason to not self backup, even if you conveniently go through all _vfp.activeproject.items collection to backup each item and thus have a general backup routine for all projects inside each project: Project directories (at least for me and I guess also for you) also contain files you don't add to the pjx. I typically have pjx outside a project folder containing all project items and more and thus could easily just copy that project folder with all its content - even from within a VFP session having that PJX open, curently. Because the PJX is not in that project folder itself, as most do it.

But even then backing up the project folders is easiest done with an xcopy or robocopy also recursively copying subfolders. Besides I already mentioned most cloud drives have a syncing application that starts with your computer and when you maintain all your projects in one root folder that's all you need to configure to backup with sync to a cloud drive.

 

[Steve Meyerson]

VFP looks at the included fileTs of the EXE only, then, it overlooks outside files of the same name.

I figured if I put the exe in different folder (other than the project's folder) it could then copy ALL the files in the project folder. I might do that.

xcopy or robocopyxcopy or robocopy

Used to do that back in the DOS days

most cloud drives have a syncing application

Usually costs, but I just don't like my stuff on the "cloud" (i.e. some unknown server.), accessible by our Big Brother (U,S.) government. I use an external drive, which I realize isn't perfect, but I find (in my years), unless proven wrong, nothing's perfect anyway.

Steve

 

[Chriss Miller]

accessible by our Big Brother (U,S.) government.

You can encrypt, then upload to a cloud.

I figured if I put the exe in different folder...

No, that wouldn't change anything. As said, an EXE (or precisely said the VFP runtime executing the EXE code) prioritizes finding files which are within the EXE. That's covering all the important source code files that are within the exe. So even regarding all the files it works with you would always backup the files built into the exe, not the current status of your project. Minus the one SCX that has the backup feature not being able to copy itself from within the EXE.

It's really still a strange concept and idea that the EXE should have the feature to backup the source project it was created from. It's easiest to incorporate that as an outside of the project mechanism, as I already suggested in several forms, cloud is not the only target. But it has the security of protecting you against theft or fire or other destruction of your locally stored external drives.

If you really prefer external drives anyway, and cater for the accidental loss by storing the external drives at other places, too, then you still don't include the backup feature of the project into the EXE, why? Is it because you think within the EXE you can also copy the PJX/PJT? WEll, that's true for any backup working from outside you use after you close the project.

Create a general backup tool that you point to projects you want to backup. Minus backing up itself. And avoid using program and form and other names you reuse in your projects. That would be the best bet on this, wouldn't it? Or make it a backup mechanism based on the simples file copy shell commands. There's nothing fancy about copying some files somewhere, you can even zip at the same time.

 

[Steve Meyerson]

I figured if I put the exe in different folder...

No, that wouldn't change anything

Even if I preceded the ..TO file name with the file's original path? Since exe would contain only its stem (or maybe some other path). Just a thought.

 

[Chriss Miller]

It's really still a strange concept and idea that the EXE should have the feature to backup the source project it was created from.

Let me entertain this thought alone in several aspects.

First, the mechanism that's thought of to maintain your sources in all their history is source control. Looking into options -> Projects you find the geneeral setting to specify a source control provider. VFPX projects obviously all make use of github and you could ask some VFPX project maintainers what exactly they use. Like Atlopes or Marco Plaza here. It's just yet another cloud storage not very different from Apples, Microsofts, Googles or Amazons clouds. Your mistrust of all of that is not even hindering you to use that, as git also can use local repositories and then from there going into external drives for duplications and the protection against hardware failures etc is just an additional step, not the main story, though.

I already told how I treat all my tek-tips related code with a cloud backup sync. It's a concept I didn't use the same way at work. What's used in company is overarching not only Foxpro source code and not even source code only and is therefore something I couldn't and wouldn't offer as a solution to anyone. Well, and the sync to cloud has one disadvantage, it only keeps one mirrored state, not the whole history. I don't need that fo the stuff I put up here, though.

But a backup with gransfather/father/son principle is easily done without more than a few shell scripts. I don't know and won't need to know what your specific concerns are, but it's simple to fulfill this without having the backup feature baked into an EXE. If it's about automating and never forgetting backup you have task scheduler, for example.

 

[Steve Meyerson]

But a backup with gransfather/father/son principle is easily done without more than a few shell scripts

I use Acronis True Image which has several optional backup schemes which can be scheduled, including differential and/or incremental versions and full backup after every X versions. It has a cloud option.

Once-a-day backups may not give history of all changes so it would have to be done more frequently depending on one's requirements and the options selected. Could get complicated.

BTW Acronis is not free, but is reasonably priced (IMO).

Steve

 

[Chriss Miller]

Even if I preceded the ..TO file name with the file's original path?

No. Even then it'll copy the same stem name file from within the EXE. The path could even be from another drive and you could change current directory with CD or SET DEFAULT, nothing helps against this mechanism of prioritizing files internal within the EXE.

 

[Steve Meyerson]

No.

Ok. I give up.

I was just looking for an easy workaround. Several others available (as you suggested).

Again, thanks Chris for yout time & help.

Steve

 

[wOOdy-Soft]

Hi Steve,
It has always been that way: Whenever FoxPro searches for a file, it first looks inside the EXE, then the working directory, then the path. That's why it finds the included scx/sct first if it has to search for the file. Search is always used if you have no explicit path attached.
If you explicitely add the specific path to the filename, then it doesn't need to search, but addresses that file directly.
This should work:
cDir = ADDBS(_vfp.DefaultFilePath)
COPY FILE ( cDir + "Stock.*") TO (cTarget)