>Hi Ed,
> Thanks for the message. Good to hear from you.
> Are you saying that:
> 1. in NT Explorer, if the user can check show all files, he can see hidden files unless blocked by a System Policy
Yes. You can block his ability to check Show All Files with a System Policy; once its checked, he can see files regardless of their system attributes as long as he has the necessary access permissions. If he can Show All Files, the Hidden attribute does nothing for you from the Explorer Browser, or for that matter, any app that uses the Shell Browser interface to select directories and files.
> 2. in a DOS window or any other application, a hidden directory would not appear but if the user knows its name, he can reference it explicitly and there is no way to prevent this?
Correct. Hidden does not mean inaccessible, it only means that by default a hidden directory does not appear in a directory list unless files with the Hidden attribute are explicitly requested (eg, they won't appear in the array created by
ADIR(aFileList,'*.*','D'), but would appear in the array created by
ADIR(aFileList,'*.*','DH').) Same with a hidden file. The hidden attribute is not an access control mechanism. Your user must be able to open/read/write/alter the file and/or directory with normal file I/O to use it within VFP, since VFP executes in the context of the currently logged-in user. Blocking it via access control methods would render it unusable from your application unless you did considerable work to use access control impersonation once the application started. I'm not even certain that a VFP app
can be set to execute in the context of another user.
IOW, if the directory C:\MyApp\Hidden were marked with the Hidden attribute, it would not appear if you took a directory of C:\MyApp without an added command line switch to request the display of hidden and system files. The user could switch to the directory by saying "CD C:\MyApp\Hidden", and could list the contents by saying "DIR C:\MyApp\Hidden". VFP could open files in the hidden directory. If Show All Files were checked in the View/Options menu of Explorer, the directory would appear in the Explorer Browser window, otherwise, it would not.
> If I understand you correctly, this solution would work for most cases. It would take a fairly sophisticated user to get around this protection. So this method is effective but not 100%--is this correct?
As long as you recognize that the Hidden attribute is not an access control mechanism as much as a legacy control on visibility, that's fine. The Hidden status is not set on a User-By-User basis the way that NT controls file access, but on a file by file basis for all users, and the user's access to the interface controls whether he can see the files and directories.
If you were trying to protect some small number of relatively unsophisticated end-users in an environment where there were other people available to perform more complex management tasks, it would probably work to keep them from accidentally hurting themselves. I would not consider it to be an effective solution with users who're comfortable with the Explorer Browser, unless System Policies were in place and enforced. There are other issues that haven't been touched on, such as the appearance of files from the Hidden directory in the Documents list because of OLE Automation, that may expose the existance of the hidden directory, too. If you really need to restrict access to data, move the database to a back end with some amount of real security like SQL Server and use Remote Views or SPT to access the data from VFP.
