I’ll ask here first, using the win32 api FindFirstFileA FindFirstFileA function (fileapi.h) - Win32 apps | Microsoft Learn
I can get the Documents and Settings folder and some subfolders in the api output. Now I cant see this using windows explorer, but if I call up a dos cmd prompt and type in cd c:\documents and settings I can access the folder this way.
Now I can also see some subfolders in this folder, all called UpdatePackage, and they appear to be identical despite being listed 4 times, ie same created date/time, same attributes.
I cant access these subfolders from the dos cmd though.
Does anyone know why these are appearing in the api, and the dos cmd but not in file explorer?
I can quote one of my messages in a parallel topic:
In future Clarion REMOVE as well as some other file-oriented functions is also resolves mapped and SUBSTed drives, virtual folders, directory injections, etc. because this is related to access rights.
Documents and Settings is a virtual folder with specific access rights. It’s need to make additional efforts to get information about files/subfolders inside it. The File Explorer does not do this. Other programs, for example, FAR Manager can work with such folders. Future Clarion will do this too - but not in DIRECTORY though
I did wonder if its some sort of virtual folder redirection.
I’ve tracked the culprit program down to Dell’s Support Assist software, Its not reassuring that Dell are using old paths.
Yes, Documents and Settings is not a virtual folder, it is the junction for the Users folder, In any case, if a “folder” has the FILE_ATTRIBUTE_REPARSE_POINT or FILE_ATTRIBUTE_VIRTUAL attribute, resolving of actual location is required to get complete information.
Beware of loops if following hard/soft links and junctions
Yes, thats the same problem search engine spiders/crawlers have following links back to previous pages spidered. It takes a not so special algorithm to make sure it doesnt get caught in an algo loop.
It seems Bitlocker enabled drives which have not been decrypted also causes an API to hang, so going to have to track down whats happening there.
DesktopAppGetKnownPath.clw (30.6 KB)
These guids with SHGetKnownFolderPath can help.
Or enumerating the MFT records
Also handy can be:
In conjunction with the clw attached
Just have in mind that result of this function can be different from expectations based on its description in MSDN.
I think thats one of the options I have changed in Win10, certainly XP as I like to see everything.
I’ve already written a template in C6 which enumerates all of these, along with other functionality the templates perform, like opening windows explorer in the app directory, and template folders, but thanks!
I’m finding an increasing number of windows API’s are not fully as described on MSDN, which can be a set back.