>>>>>>Hi everybody,
>>>>>>
>>>>>>I have the following line of code
>>>>>>

>>>>>>copy memo contents to (lcFile)

>>>>>>
>>>>>>I found that it fails for the regular user if the file already exists in the directory. The user does have read-write access to the parent directory (and I assume to all its children?).
>>>>>>
>>>>>>Do you find this to be the case for you as well and what will be the solution?
>>>>>>
>>>>>>Thanks in advance.
>>>>>
>>>>>Try SET SAFETY OFF, maybe that helps?
>>>>
>>>>No, it didn't help. I also added code to delete the file (ERASE (m.lcFile)) if it already exists and now I'm getting 'File Access denied' on this line of code.
>>>>
>>>>So, assuming that this file originally inherited hidden (or read-only) attribute of the directory and was not changed, is there a way to overwite the file with Copy memo command (or any other similar command) without first trying to change the file's attributes?
>>>>
>>>>We're getting the similar problem with FoxUser and also I don't know in how many places we're getting this error, so I'd like to have the universal solution.
>>>
>>>Anyone has ideas of how to solve this problem? We get more same errors and I'm not sure how to solve except for checking if the file already exits and trying to create with the different name.
>>
>>Is this a local directory or a network directory? If it is a network directory you might want to check both the Security profile as well as Sharing Permissions.
>
>It is supposed to be local directory (ProgramData) and it also supposed to have read/write access. However, the application is running through Citrix.

Is the file in use (i.e. opened by another process)? If so the file attributes don't matter -- you can't erase nor rename a file that is currently open.

On occasion I'd run into problems with antivirus programs. Processes like PACK would frequently not work when an antivirus is running.. As you know, PACK does the following:

1. Create temp file for DBF (and FPT if one exists)
2. Copy records that aren't tagged with delete to temp file
3. Close original DBF (and FPT) and temporary file(s)
4. Delete original DBF (and FPT)
5. Rename temporary files to with original name

Apparently what happens is that the antivirus kicks in somewhere between step 2 and 5 and starts scanning the temp file -- causing step 5 to fail because the antivirus has the file open. As a result you end up with the DBF (or FPT) missing and a temporary file.