It seems to me that you just implied the answer. The control access would be class whose constructor takes a path. It would throw if the path doesn't resolve to an existent file or directory. The class would have some getter functions that tell you the state of the file/directory, and some setter functions that _try_ to set the permissions for the file/directory. If they cannot change the access controls, because the granularity is wrong, or the process has not enough priviledges, or just because, then they would fail silently leaving the burden of checking that the access has been effectively changed to the user. The user would check by using the getter functions. This way, operative systems with less habilities do not hamper the development in those more capable systems. Again, the key is that the setter functions should only attempt the changes. ++Hector C. --- Sebastian Redl <sebastian.redl@getdesigned.at> wrote:
Calderon Hector wrote:
I doesn't have to support every operative system out there. Can it be done to support the major operative systems at least?
Still not easily. Windows and Unix have quite different permission systems: Windows uses access control lists, which support fine-grained control of who is able to access which files. Unix uses user/group/world permissions, which are far less fine-grained, with some *nices in some configurations supporting POSIX ACLs too. (For example, this is a compile flag that must be enabled for the file systems in the Linux kernel.)
Finding a common interface for even these two is therefore very difficult. I'm sure though that there would be interest in any ideas you might have.
Sebastian Redl _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
---------------------------------- __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com