How to copy from a sub-folder to the main folder 1

[SitesMasstec]

Hello colleagues!

I have the following

* Current folder
DirCorrente="'" + SYS(5) + SYS(2003) + "'"

* sub-folder (\BKARQTMP) inside the current folder
DirTemporar="'" + SYS(5) + SYS(2003) + "\BKARQTMP\*.*" + "'"

I want to copy the files inside the sub-folder (\BKARQTMP) to the main (current) folder, but I know it is not advisible to use this way (but in fact it works fine):

COPY FILE &DirTemporar TO &DirCorrente

But the command COPY FILE (DirTemporar) TO (DirCorrente) shows 'Invalid path or file name error'.

What to do?



Thank you,
SitesMasstec

 

[SitesMasstec]

Or this is correct, even as if SYS(5) + SYS(2003)= C:\Program files ?

* Current folder
DirCorrente= SYS(5) + SYS(2003) 

* sub-folder (\BKARQTMP) inside the current folder
DirTemporar= SYS(5) + SYS(2003) + "\BKARQTMP\*.*" 

COPY FILE (DirTemporar) TO (DirCorrente)

Thank you,
SitesMasstec

 

[Olaf Doschke]

First of all when you copy files with joker *.* this also has to be added to the destination folder or in other words the FIOLENAME2 of the parameterization has to be a file name, too, it can't just be a directory. Especially if it already is a directory the command you specify would try to create a file with the same name as the directory, a file name without extension, but since that name already is taken as a directory name you get the error "cannot create file ..." And that should tell you that VFP understands the FIOLENAME2 as filename, also when it is a directory, also when you specify it with trailing \, which means it can't mean a file name.

Secondary, you can't write into program files or most any system directory, only system directories like the user profiles documents folder that specifically is meant to store documents of that user or appdata, a specific folder for application data. You can write into \program files\your app\somedatafolder, when your installation created that folder with write permissions. as a data subfolder. It's not really recommended, though, apps should have application specific data in an appdata folder, especially when that is not user-specific bit for multiple users an a system. And even off program files and appdata in case of data shared for multiple users, then it would go into a file share, and you create those outside windows system folders, typically even on a drive separate from the OS, eg d:\yourappdata\ and on clients this may be mapped as X:\ or addressed as UNC path \\yourserver\sharenameofyourappdata
OK, that system folder topic aside, to copy from a subfolder of the current folder to the current folder you'll need

* Current folder
DirCorrente= SYS(5) + SYS(2003) + "\*.*" 

* sub-folder (\BKARQTMP) inside the current folder
DirTemporar= SYS(5) + SYS(2003) + "\BKARQTMP\*.*" 

COPY FILE (DirTemporar) TO (DirCorrente)

Bye, Olaf.



Olaf Doschke Software Engineering

https://www.doschke.name

 

[Olaf Doschke]

As we're at this topic, let me show you why it's a bad idea to write into "Program Files":

StrToFile("hello from write redirection",Addbs(GetEnv("ProgramFiles"))+"uacwriteredirect.txt")
? FileToStr(Addbs(GetEnv("ProgramFiles"))+"uacwriteredirect.txt")

declare integer ShellExecute in SHELL32.DLL ;
 integer nWinHandle, ; && handle of parent window
 string cOperation, ; && operation to perform
 string cFileName, ; && filename
 string cParameters, ; && parameters for the executable
 string cDirectory, ; && default directory
 integer nShowWindow && window state

=ShellExecute(0,"open","","",GetEnv("ProgramFiles"),1)
=ShellExecute(0,"open","","",Addbs(GetEnv("USERPROFILE"))+'AppData\Local\VirtualStore\'+JustStem(GetEnv("ProgramFiles")),1)

The first two lines will make you think you can write into program files and also read back from this written file. That's what the UAC file redirection is all about, it's not just one way, it's two-ways, when you request to read from a system directory you're not allowed to write to and the file does not exist there, the file will be read from the directory the write was redirected to.

So there's no problem?

Well, there is, and it's a big-time problem. The only reason you can read the file back and see no problem is, because you execute all this under your windows user account. To understand why this is problematic you have to know where the redirect puts files: They are written into your user profile an appdata\local\VirutalStore and there in the corresponding sub-directory. The following code will open up Windows Explorer to show you the program files directory has not stored the uacwriteredirect.txt file, instead, this was written to the VirtualStore directory in your user profile. So you find it in only one of the Windows Explorer windows the two ShellExecute calls open up. If indeed, you have turned off UAC, you'll find the file in program files.

So still no problem, right? Well, the problem is that any file in any user profile is only available to that user. So when you want this to work for all users, this is impossible with UAC on.

So turning off UAC is the solution? No, it is not, turning off UAC means opening doors to all kinds of malware. So it might be a personal solution, a company solution, if they don't find a way to write the software so it uses the recommended system directories for shared access of all users, if not even a file share, as I said earlier. But it's not a good solution when you make this a requirement for your software.

As you are the programmer of software, simply please write it according to MS rules and recommendations, in short: best practices. Any user can access the special user profile "Public" and since Vista such directories also are not differing by OS language anymore, the display in different languages is managed by a desktop.ini entry for a language id used by Windows explorer. Besides, there are API routines to get to such special folders.

But to conclude once more: There is a simple best practice for shared data no matter if you do install on a server used via remote desktop or on every single client: File shares.

The current crisis makes working remotely from home a new norm not only for us software developers, but also users of it. Well, one easy way to establish it is to let employees connect to their own workstation and use it remotely from home. That requires no terminal server licenses and CALs, that's a Windows feature available since XP, IIRC. And there you'll still have data wherever it was and is, nothing changes. the workstation PCs just have to stay turned on 24/7.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name