1. David Vasconcelos
  2. PowerBuilder
  3. Thursday, 18 February 2021 16:45 PM UTC

Have an issue where a PB is reading a file but not the one we think it should be.  Means there is a copy of a file somewhere on the users PC.  Is there a way find a file using just the name and getting its path/directory.

Tried using DirList but get back garbage..

 

 

Miguel Leeuwe Accepted Answer Pending Moderation
  1. Thursday, 18 February 2021 16:53 PM UTC
  2. PowerBuilder
  3. # 1

Hi,

I'm not sure if I understand what you mean, but - for debugging purposes - you can use tools like 'process monitor' from SysInternals to see what's happening while your powerbuilder application is running.

Chris also posted a link the other day of his web site:

https://chrispollach.blogspot.com/2020/08/explorer.html?m=0

I'm not sure if it also shows which files are being found where though.

regards.

Comment
  1. David Vasconcelos
  2. Thursday, 18 February 2021 18:26 PM UTC
Ole does not work since you need to have the path for it to work.
  1. Helpful
  1. Miguel Leeuwe
  2. Saturday, 20 February 2021 10:20 AM UTC
Hi David,

You say: "there is another copy somewhere on there C drive, but we are unable to locate it. We know it exists just that we do not know where it is. There maybe some sort of security that is blocking a normal file search using the file explorer. I was looking for a function I can run from powerbuilder that could give me the files location. "



Have you tried opening up a command prompt and doing:

cd \

dir fileIamLookingFor.* /s



I've stopped using the search of windows explorer a very long time ago. It's slow and not trustworthy.

regards
  1. Helpful
  1. Miguel Leeuwe
  2. Saturday, 20 February 2021 10:21 AM UTC
Corrected, first go to the drive by typing "C:":

C:

cd \

dir fileIamLookingFor.* /s



  1. Helpful
There are no comments made yet.
Kevin Ridley Accepted Answer Pending Moderation
  1. Thursday, 18 February 2021 18:03 PM UTC
  2. PowerBuilder
  3. # 2

Why not use the full path to the file instead of opening just by file name?  Then there's no confusion which file you're opening.

Comment
  1. Kevin Ridley
  2. Thursday, 18 February 2021 18:31 PM UTC
I don't understand. You don't have the source code? You can potentially put the path in an ini file or similar. Seems like a super easy change.
  1. Helpful
  1. David Vasconcelos
  2. Thursday, 18 February 2021 20:03 PM UTC
Sorry Kevin, was over simplifying.. yes it can be changed. The app has never had an issue. The file resides in C:\windows and has been there for 10 plus years with out any issues. And since the "Path" is controlled by security windows was always the one that got hit first. Hence the opening of the file was never an issue and since windows folder was protected users could not touch it. (recently that changed and is no longer secured). Since it was never an issue there was no need to change or give us a reason to change it and works (almost) perfect today. We don't know how the file got to the virtual directory we can only guess. The file is read on a daily basis and written/updated several times a month, maybe a corrupted user profile so windows did not know what was good from bad.. who knows. We found it and deleted it and now the app on the users machine is working fine, it was one machine out of hundreds, but will keep an eye on it and determine if in fact we should fully qualify the path or move the file. I never know about this virtual store directory until today (see comments) no sure how many other programmers know about it. But just another day in Microsoft virtual reality. ?
  1. Helpful
  1. Miguel Leeuwe
  2. Thursday, 18 February 2021 21:51 PM UTC
I agree with Kevin,

1) If you want the file to be in the %windir%, then use that path to access the file.

2) Personally I would use another folder to be honest (like maybe the folder where the EXE is. For that folder it wouldn't matter which path it can be found in, it will always first try to find it in the current directory).

3) If that's not what you want, maybe another thing you can do is store the file as a blob in the database and write it to the windows %temp% folder when you need to use it.

4) Also, if you're not sure of the PATH in windows could cause the file to be found elsewhere, you can make sure that the folder that you want to be searched first is the one you want by modifying the path of the session of your powerbuilder application. Just prepend the existing path with the one you want.



Doing anything else leads to the problems you're finding yourself with now. Maybe I don't understand the problem, but I think there are better options than just "randomly opening a file wherever it turns out to be".

regards.
  1. Helpful
There are no comments made yet.
John Fauss Accepted Answer Pending Moderation
  1. Thursday, 18 February 2021 19:39 PM UTC
  2. PowerBuilder
  3. # 3

Microsoft implemented the "Virtual Store" concept in Vista. In days of old, it was common practice for apps to read/write configuration and ini files, etc. using the same folder where the app was installed... and this was typically C:\Program Files. Later on, when security was tightened in Windows, this practice would no longer work unless the user had admin rights. To prevent apps from crashing while protecting unauthorized changes, Windows was enhanced to intercept attempts to write into protected folders and re-directs the activity to the user's Virtual Store. Read attempts by unauthorized users into protected folders are automatically read from the Virtual Store if the file exists there. So, once written there, that's where the real file resides.

This is all well and good, and I have no doubt that a Vista engineering team within Microsoft patted themselves on the back for their ingenuity. The deception falls apart, however, when an admin user makes a legitimate change to what they believe is the "real" file residing in C:\Program Files... the non-admin user will never see the updated file because Windows always gives them the non-updated version that resides in their Virtual Store.

As Kevin correctly suggests, the fix is to stop reading and writing files from the app's protected installation folder.

Comment
  1. Olan Knight
  2. Friday, 19 February 2021 20:27 PM UTC
Please note that there are REGISTRY entries that also have this "Virtual Store" protection applied.



The 32 bit APPNAME VirtualStore hive location is here:

HKEY_CLASSES_ROOT\VirtualStore\MACHINE\SOFTWARE\WOW6432Node\APPNAME\App_Folder



The location of the Drive Mappings is here:

HKEY_CURRENT_USER\Network

  1. Helpful
  1. John Fauss
  2. Friday, 19 February 2021 20:38 PM UTC
I was not aware of this information, Olan, but it makes sense (insofar as anything that Microsoft does makes sense). Thanks for letting us know!
  1. Helpful
  1. Miguel Leeuwe
  2. Saturday, 20 February 2021 10:14 AM UTC
yes, doing a search in the registry on "VirtualStore" and simply deleting those entries has solved more than one problem for us with certain users!
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.