Thought we haqd it...but...

[john at timescape.com]

Thanks for the suggestions.  I've checked which p.exe is actually being used (and any and all p.exe's are all the same file using a binary checksum), same with the license authorization files... all the same.  I will check the zip file he got to see if a particular  p.exe came with the files for the license, but I don't think so... just some file that you had to rename to the license file name.

It seems to be that filePro (the executable programs including p.exe of course) are expecting there to be a C:\fp folder, and if there is, they go on their merry way to do the right thing for everything else.

We only found this out because I wanted him to consolidate all his many "fp" folders into the one new onethat is living on his new NAS device.  He wants to be able to backup this one huge device and be sure he can get back to his data and programs should there be some calamity.  

I'm wondering if filePro pokes into the registry the first time the filePro license is activated or something and from that point, it keeps looking in *that* noted location... but I actually really doubt this.

As to your question about *which* p.exe is being actually run...

I am doing that stupid thing of "assuming" that the system finds the precise p.exe that I want because of putting the Y:\appl\fp as the very first search location in the PATH variable.  It would find *this* particular p.exe first, wouldn't it, and should then be looking in the PFPROG location that filePro constructs  by adding an "\fp" to the PFPROG environment variable... which becomes  the very same place.  I can't see why any part of filePro is looking into C:\fp for anything. ☹

Thanks again for your suggestions, Jose, they have made me wonder if there might be a %PATH% specified for the %user% this person runs.  Maybe a personal user PATH has precedence over the PATH specified in a batch script?  Nah, that can't be possible.  Am I allowed to put the drive letter of the mapped drive into the PATH variable as I have done? Maybe *this* is being ignored or something, which means it would very definitely find some other p.exe than I want it to find...
 
/john

P.S.  I don't think he ever actually *used* the c:\fp and C:\filepro folders on either of his two access machines.  There is the super gotcha that by putting these directories into the actual root directory, they can't be mounted as a usable mapped location since mapping any drive and share clobbers the name of the final shared folder.   (FilePro can then not add its "fp" to PFPROG and "filepro" to the constructed PFDIR.   This is why he started with making a \appl folder under the top level folder on the NAS drive which is \home.

In the final analysis, I suppose there is no reason why we couldn't leave things working as they do now, and just keep the C:\fp where it is, since once filePro is operational license-wise, it does not seem to look at C:\fp for anything... which is the behavior we want, but I wonder if somewhere else further along the line some other critical thing isn't going to work because it does some other check into c:\fp for something else.

Also, he does not use any "runtime" programs, only the "d" programs.  He is a single user.
 
John,

As I read through your post one question comes to mind: How does runtime check the licensing validity and based on what?

Meaning, does fp check license by constructing dynamic pathway or relative to the p.exe location?

If you moved fp to xfp, which p.exe is being executed?  Did you also change your menu vars to point to xfp?

I would start by checking user %PATH% and identifying each possible p.exe you have.  If you have multiple versions/licenses, I would expect that each license may have its own p.exe.

If fp insists that c:\fp exists for it to validate license, then you may be stuck with keeping this directory but renaming sub-directories to accomplish what you intended to do when you renamed fp to xfp.  In other words, just give fp access to validate the license but not to the runtime.


Regards,


Jose



On 4/13/24 09:26, John Esak via Filepro-list wrote:
> I thought we were done.  Eventually, after fixing glitches, extra stuff and pairing the calling batch script down to its most atomic needs, the program seemed to be "working" in all aspects.
>
> Here is what worked, which btw, is the HelpFile suggested "correct" way to assign the filePro PATH variables in the situation we have - so that filePro itself can find the user designed filePro folders, and its own executables and config files.
>
> The batch script should be self-explanatory if you know that directly under the root of the Y: filesystem root is a folder "\appl" and below \appl are "the two folders fp" and "filepro" both on the same level (y:\appl\fp and Y:\appl\filepro)
>   .
>
> @echo off
>
> Net use Y: \\ds620-1\home /persistant:YES 2>NUL
>
> set PFDSK=Y
> set PFDATA=Y:
> set PFPROG=\APPL
> set PFDIR=\APPL
>
> set PATH=Y:\appl\fp;;%path%
>
> p.exe UserMenuName
>
> As I said, this is as simple as it gets, and everything worked fine, 
> and that was that.  Before that we had copied the entire "fp" and 
> "filepro" folders from their previous location on another mounted 
> (mapped) filesystem G:.  in order to have them be under Y:\appl as 
> they need to be. (Y: is a new NAS array stack made by Scenology.)
>
> (Unbelievably, there was/is a *third* and *fourth* pair of filePro folders under the C:\ of the two computers which access this LAN (so on one machine c:\fp and C:\filepro, and the same for the second machine)   It's not worth commenting on this maze of filePro programs and data, it is just the way the gentleman did it, and it has worked that way for him for years, decades actually. He bought his latest copy of 5.0.14d9 in 2010. I had forgotten the strange licensing format and location for the license file for 5.0.14 but after a while, determined what used to be done in that regard, and it is the same authorizing key in all the fp locations.
>
> Okay, if you've stayed with me. We were happy, but the man who runs the system was considering the suggestion I had made to consolidate all of his working "fp" folders into just ONE all encompassing "fp" folder somewhere. that would run the various datasets he has on different mapped drives.
>
> While the above batch script *was* running, he had seemed to have some trouble with a new menu or something, and to isolate the actual location of the "menus folder that was being accessed, he put an "x" in front of the C:\fp folder on the first machine (the one he was running things from at the time.  Meaning, he was trying to make the C:\fp folder invisible to anything filePro-based by renaming the "fp" folder to "xfp".  Actually, a great diagnostic technique.
>
> Guess what, and this is why I'm writing such a detailed explanation... the above batch script simply errored out with the message "This product has not been formally registered with FP Technologies..."  or something very close to that.  A big black screen, and then no going further.
>
> Help me figure that one out, and we will be a long way into solving this strange PATHing problem.
>
> Why is filePro checking in C:\fp for the correct license key?
>
> Now, just to be really crazy, here is another piece of info that is sort of impossible.  After putting c:\xfp back to its original name c:\fp, the script starts working again (Quite obviously because it finds a C:\fp folder, (and maybe the license key there??  BTW, does the DRIVE you are running a batch script on have *anything* at all to do with what is inside the script???  I can't imagine that it does, but I do see on most Windows 10 machines a variable called "homedrive" set to C:.  Don't know enough about windows to know why this is there.
>
> Meanwhile, after putting C:\xfp back to C:fp, more impossibility seems to happen.   when I had the gentleman enter the filePro Directory (the ? on the main filePro menu) and from there have him edit the config file that is being used, IT IS CLEARLY THE file "Y:\appl\fp\lib\config" and not the "C:\fp\lib\config" on the machine he is running the batch script from.
>
> This means (at least it appears to mean to me) that filePro needs there to be a C:\fp folder for licensing up correctly, but then goes ahead and uses the "fp" location specified in the calling batch script! It seems to use the PATH variables as specified in the script in the first place... why doesn't it look for the license key there as well?!!! Very strange.
>
> 		So, that is problem 1.  This second one is part and parcel of everything above, but it is so outlandish, that nothing lets me give it much credence at all, he has shown me repeatedly that the "fix" he came up with below for the batch script seems to fix the problem!!!  However, as  you all can see, the PFPROG variable has been change to something that will NEVER allow filePro to find the correct location of the executables and other configuration stuff.  (Or, will it???? It works as we step through the file echoing each variable as they are constructed and filePro finds menus, filePro folders, etc., etc.   Maybe the PFDATA variable can be duplicated in the PFPROG variable??? And the program just uses the %PFPROG%\fp if it comes out to whatever it would have constructed itself?  Sorry, that's too convoluted even for my broken old mind... but I can not understand why the following, simple change to the batch script fixed the problem of not having a C:\fp folder, and DID NOT BREAK ANYTHING ELSE!!!
>
> ☹
>
> Here is his fix:
>
> @echo off
>
> Net use Y: \\ds620-1\home /persistant:YES 2>NUL
>
> set PFDSK=Y
> set PFDATA=Y:
> set PFPROG=Y:\APPL
> set PFDIR=\APPL
>
> set PATH=Y:\appl\fp;;%path%
>
> p.exe UserMenuName
>
> I'm not sure how *anyone* can help without a system (the system) to try things yourself, or make changes and test them as you go, but after weeks of trying to shoot this, I have no solution.
>
>
> BTW, the person running this 5.0.14d9 system did purchase it, it is clearly licensed to him and he is only operating it on his own home LAN.  Him being 6 years older than I am, and I'm 75! Tells me not to try and fix his system by telling him to just upgrade to something newer. For someone like myself who still, amazingly , helps legacy clients from time to time, I don't mind buying current copies of filePro.  It is the only fair and intelligent thing to do.
>
> However, this is something that I just don't understand about how the 
> filePro internal PATHing works, and want to figure out just to stay 
> conversant with how one would implement other even more complicated 
> "virtual" installations.  .  The FP Web still intrigues me, and I'm 
> doing some testing now on whether my latest screen reader can keep  up 
> with enough of it to go ahead and get a copy, or just go with the 
> latest version
>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at mailman.celestial.com
> Subscribe/Unsubscribe/Subscription Changes 
> http://mailman.celestial.com/mailman/listinfo/filepro-list
_______________________________________________
Filepro-list mailing list
Filepro-list at mailman.celestial.com
Subscribe/Unsubscribe/Subscription Changes http://mailman.celestial.com/mailman/listinfo/filepro-list