Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
How to check whether or not Exe is in use
Message
De
16/02/2009 15:27:12
 
 
À
16/02/2009 08:30:43
Information générale
Forum:
Visual FoxPro
Catégorie:
Fonctions Windows API
Versions des environnements
Visual FoxPro:
VFP 9 SP1
OS:
Windows XP SP2
Database:
Visual FoxPro
Divers
Thread ID:
01381527
Message ID:
01382189
Vues:
56
>>>Using FOPEN('some.exe',1) to check whether or not the exe is in use will give accurate results if the folder is readwrite. If fopen() succeeds, then the exe is not in use. If fopen() fails, then the exe is in use.
>>>
>>>However, if the folder is readonly fopen() will always fail, even if it is not in use.
>>>
>>>Is there another way (preferably an API) that can tell whether or not the exe is in use, no matter by whom or by what process?
>>
>>Maybe Thread#1374298 could help.
>
>Thanks for the link to this recent thread. That link ultimately leads to Sergey's http://www.berezniker.com/content/pages/visual-foxpro/who-has-files-open-network, but it is of no use in my situation, as it produces an 'Access denied' message. That is normal and predicted behavior by the way, because in my situation the user is not an Administrator. The user running this program must be a member of the Administrators or Account Operators local group. (I'm not sure what 'Account Operators local group' exactly means.)
>
>I wonder why Microsoft decided to unveil such information only to Administrators.

Probably there are scenarios where that information could be misused by bad guys, so it could be a potential security issue.

If you want to use Sergey's utility I can see two options:

1. Maybe it's possible to add the specific rights required to use the utility to a normal user or group. This would probably be done through the Group Policy Editor (gpedit.msc) on the domain controller. I don't know what those privileges would be, or whether it's even possible given that we're talking about built-in security groups.

2. Another option might be to RunAs the utility with higher privileges than the regular user. RunAs would need credentials (user name and password) but the user may not need to know these, they could be baked into your application. This could be difficult to manage if such user names/passwords are changed regularly.
Regards. Al

"Violence is the last refuge of the incompetent." -- Isaac Asimov
"Never let your sense of morals prevent you from doing what is right." -- Isaac Asimov

Neither a despot, nor a doormat, be

Every app wants to be a database app when it grows up
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform