missing output when my program is run from C: drive 1

[Bryan - Gendev]

In my new program to garble a project from a genealogy program I am attempting to read entries from an ini file which is part of that project.

When my program is run from the development folder on P: drive the output I create is
---------------------
Log of garbling on the XXX project - SAMPLE
Start of garbling run at 17:27:01 on 14/09/2017
In XXX ini file - SAMPLE.ini

RESEARCHER
Name GenDev - Removed by XXX Garble
---------------------
However when run from the C:\program files folder I get ]
---------------------
Start of garbling run at 17:29:16 on 14/09/2017
In XXX ini file - SAMPLE.ini

RESEARCHER
Name - Removed by XXX Garble <<<<<<<<<<<<<<<<<<<<<< missing entry
____________________

The contents of the Name entry is missing.

Why could this be?

The code in part is ( I've just used one entry as an example.)

lcContent = ''
cContent = ''
lcLine = ""
cMessagetext = ""
cSection = 'Researcher'
Strtofile(UPPER(cSection)+ lcCrlf, ('garble.log'),.T.)
cEntry1 = 'Name'
For lnI = 1  To 1
	lcLine = Eval("cEntry" + Transform(lnI))
	Wait Window UPPER(cSection)+'  ' +lcLine Timeout 2
	cContent = readini(inifile,'read',cSection,lcLine)
	lcContent = Eval("cContent") <<<<<<<<<<<< tried as a test - same when just using cContent
	Wait Window lcLine+' ' +cContent Timeout 2
	If ldoit
		readini(inifile,'write',cSection,lcLine,cPath)
	Endif
	cMessagetext = lcLine +' ' +lcContent + " " + cPath + lcCrlf
	Strtofile(cMessagetext, ('garble.log'),.T.)
Endfor

Function readini
&& uses full path name for file
Parameters  tcFileName,mode,tcSection, tcEntry, tcValue
Local lcValue
Declare Integer GetPrivateProfileString ;
	IN WIN32API ;
	STRING cSection,;
	STRING cEntry,;
	STRING cDefault,;
	STRING @cRetVal,;
	INTEGER nSize,;
	STRING cFileName
Do Case
Case mode = 'read'
	lcValue = ReadFileIni(tcFileName,tcSection,tcEntry)
	If Isnull(lcValue)
		lcValue = ''
	Endif
	If Vartype(lcValue)="C"
		Wait Window lcValue Nowait
	Endif
Endcase
Return lcValue

 

[Olaf Doschke]

C:\ root folder is a protected folder, no program can easily write out files to C:\ root level.
While most people run their PC as admin, even copying a file to C:\ will most often cause a prompt to ask for admin permission to write there.

But if you do so, later a program reading from C:\ will find the file, but most problably read it from the VirtualStore folder of your profile.

I just did the experiment and put a test.txt file on C:\. I am asked to allow this.
VFP can see the file via FILE(), but reads a different content via FILETOSTR() and that is explained, as I already had a test.txt in C:\Users\<<my windows accountname>>\AppData\Local\VirtualStore\test.txt
That content is read in instead of the content of C:\test.txt

So look out for an INI in your VirtualStore folder. IIRC the GetPrivateProfileString API function has the tendency to create non existing INI files, so it might have created the ini empty in your VirtualStore when you used it on C:\your.ini before C:\your.ini existed. It might also not see C:\your.ini as it's running in some other context, though API function will run with the current process permission and identity.

For sake of simplicity, don't use C:\ root for any files. If you want something for access to anyone, you have the C:\Public folder for that and in general, like you don't eat from the floor, as tidy as you may keep your house, you don't store anything on C:\ or any other root drive folder, even though other than the OS drive are not protected as C:\. You eat food from a plate on a table, usually, sitting on a chair. That visual analogy suggests at least two levels of directories for any file to be in and your EXE (the "consumer" of the "food") also at least within one folder. Besides having system folder specifically tailored to whatever access level you want to grant to all computer users, a certain user local or roaming, using any PC/client/workstation in a LAN.

Bye, Olaf.

 

[Bryan - Gendev]

Olaf,
Thanks for your lengthy reply.
You say 'C:\ root folder is a protected folder, no program can easily write out files to C:\ root level.' I agree.

I do state in my post that my new program is located in a C:\program files\ folder as is normal for my VFP and other programs.
The genealogy project could be on any drive that it was originally written to. In this case I have a copy of the project on my P: drive in a subfolder and that is where both the ini file and log files I describe in my post were written to.

I'm not sure how much of what you have written is relevant in this circumstance?
Regards
GenDev

 

[Olaf Doschke]

Didn't you say you only had a problem on C:\ and not P:\ ?

I would simply not use P:\ root for reasons of similarity, access is not limited there, but still cluttering root drives with files is a bad practice.
You keep an ini typically in a application data folder, which would be C:\ProgramData\appname\ since Vista. or more generic ADDBS(GETENV("ProgramData"))+"appname\"

Bye, Olaf.

 

[TamarGranor]

Folders in the Program Files hierarchy are protected, as well. Put your data somewhere else.

Tamar

 

[Bryan - Gendev]

Olaf,
Nowhere am I using the root of a drive.
My programs are developed from folders on my P: drive and install in a folder in C:\program files as is common to all my VFP programs.
My problem that I am seeking advice on is - is there any explanation why an exe run from my dev folder on the P: drive works as programmed whereas when run from the particular C:\program files folder the output to the log file is incomplete?
As you can see from the code I provided above.

cMessagetext = lcLine +' ' +lcContent + " " + cPath + lcCrlf
Strtofile(cMessagetext, ('garble.log'),.T.)

The wrong output produces lcLine twice rather than lcLine +' ' +lcContent

In all other respects my program operates as I have programmed it

Regards
GenDev

 

[Olaf Doschke]

OK. sorry, I must have misread something.

Well, you better debug what happens. Your readinin seems to fail on C:, either not finding the ini or the section within the ini.
If you included the ini you'll make it impossible for the GetPrivateProfileStrin to read from the ini within your EXE, it needs to be an excluded separate file.

Bye, Olaf.

 

[Bryan - Gendev]

In an attempt to solve my problem I have added a ? inside the loop and when I run the exe in the ide I see LcContent on the left of my form as expected..
When run from C:\programfiles\folder I do not see the LcContent values.
However I have moved the test project to a folder on my C: drive which is a SSD and I now get the correct result.
As my P: drive is a HDD it must be due to the access time to the spindle driven disk although when I run the exe from the P: drive it works.

Regards
GenDev

 

[Olaf Doschke]

You're making an assumption here, that has no good foundation.
Any operation like GetPrivateProfileString or FileToSTR or FREAD will wait for what the file system (and thus the drive) returns, no matter if SSD or classical HDD.

You don't show your ReadFileIni so we can only guess what happens.

In the end things like GetPrivateProfileString will return nothing, if you ask them to read non existing entries or non existing sections or non existing ini file names. Thus you see nothing read and also get no error.

Besides not knowing your ReadFileIni function (as you only provide your readini function) we also don't know your INI and any current DBF open which you finally want to read via field name. And since all this is related to your name garbling I assume this is about confidential data you can't show here.

I can only advise you to start up the debugger, look into the trace and locals window and single step through your code to see where what is read or not read. I assume you simply have some misconfiguration or outdated ini file.
Edit: As Tamar says below, one explanation maybe your ini file within program files, which generally will make it readonly, which will be problematic with your readini(inifile,'write',cSection,lcLine,cPath) call, most likely.

Bye, Olaf.

 

[TamarGranor]

Once again, folders in the Program Files hierarchy are protected. Trying to write there is a problem.

Tamar

 

[Dan Freeman]

Once again, folders in the Program Files hierarchy are protected. Trying to write there is a problem.

Or read there.

This is really fundamental to making an application work and has absolutely nothing to do with Foxpro.