> I see your point. However, since the function you are implementing is in
> kernel32 anyway you could abstract it away and make both functions
> (CopyFile and ReplaceFile) call some internal function. That way you
> would get rid of the locking completly which is argueably somewhat ugly.
On closer inspection, CreateFile actually seems to take care of this with the "security attributes" and "template" parameters.
It does not look like the security attributes are implemented yet (or the call to get the security attributes for a file) but since CreateFile already handles this it seems unnecessary to add a new break-out function. You will likely find the attached more to your liking.
Erich Hoover
ehoover@mines.edu
On 2/28/07, Felix Nawothnig <
flexo@holycrap.org> wrote:
Erich Hoover wrote:
>>>> The "right" way would probably to do the copying yourself by
>>>> read/write.. but I dunno.
>>> Except that it would ignore the permissions issues that have already
>>> been coded into the copy routines (and any updates that may eventually
>> No, CreateFile (and friends) does the permissions checks (which you
>> would still have to call).
> That was worded poorly, Copy/Move already handle copying file attributes
> and I imagine would eventually implement copying the access control list
> information. Implementing ReplaceFile as calls to either Copy or Move
> takes these issues into account.
I see your point. However, since the function you are implementing is in
kernel32 anyway you could abstract it away and make both functions
(CopyFile and ReplaceFile) call some internal function. That way you
would get rid of the locking completly which is argueably somewhat ugly.
Felix