Failed to open stream: Permission denied (disappearing .fpt that is not regenerated)
Opened this issue · 1 comments
Hello,
I have previously contacted you in regards to the php-xbase plug-in, and am happy to report that my original efforts to utilise the php-xbase plug-in to send data from a MySQL database to a .DBF file had been successful.
However, an attempt to use the same plug-in to perform the same functionality with the same code in the same folder on a different .DBF file has resulted in the following error message:
Warning: copy(C:\datafolder\wws_customers.fpt): failed to open stream: Permission denied in C:\projectfolder\vendor\hisamu\php-xbase\src\Memo\AbstractWritableMemo.php on line 104
The .fpt file has disappeared and has not been re-added to the data folder, resulting in the table being unusable. This issue exists despite the same code existing (except for different links) for the previous successful attempt to send data to a .DBF file.
The debugging process has included the following processes:
- Folder permissions were checked, as this appeared to be an issue when I previously contacted you and your group, and the results confirmed that users could read and write to files, so permissions must not be an issue
- The .DBF, .FPT and .CDX files had various upper and lower-case lettering, and had been previously listed as a possible issue, though this difference in lower-case has always existed, and was subsequently not found to be a cause of issues in the past (the code preserves the upper and lower-case lettering)
- Comparing the original file that successfully added records to a different .DBF file side-by-side with the new file (no discrepancies found)
- Determining when the plug-in reads a memo field, ensuring that all memo fields are read (all memo fields were successfully read)
- Outputting memo data that is entered via the TableEditor (all memo fields displayed expected data)
- Outputting data that is to be sent to pointers, to confirm correct data is being stored there (all data displayed was expected)
- Outputting cloneFilepath and filepath in the AbstractWritableMemo file to confirm file path locations for the clone and main file paths respectively (both file paths utilise the same data folder, just like previous efforts to successfully utilise the php-xbase plug-in)
- Outputting current user, and which user executed the script (they were both the same, as expected)
As a test, I created a copy of the .DBF file that is to be modified, but only with a few fields. None of them were memo fields. Data was sent correctly and appeared in the .DBF file as expected. Once a memo field was added to the .DBF copy, the warning message re-appeared. So this, in my opinion, means that the target .DBF file is not corrupted.
The .DBF files used, along with its supporting files, are in the same data folder.
The only difference of any kind that I have noticed between the previous successful attempt to send data to a .DBF file and this unsuccessful attempt is that there are three file formats missing from the current attempt, which is a .BAK, .TBK and .ERR file. Again, these should not prove to be significant. A .BAK and .TBK file refers to backups that are generated if a significant structural change is made to a .DBF file, which is not the case here. A .ERR file refers to what is effectively a text file to list any errors that may occur.
With all of the above information in mind, are there any other possibilities that could possibly account for the different outcome between the two applications of this plug-in? It feels like I have exhausted all reasonable avenues to account for any differences in code or files. Any helpful feedback would be greatly appreciated.
Regards,
Craig
@CPWebPro
As far as I remember, we have already discussed this problem in #116.
Please check editMode in TableEditor. What value is used? Can you change it to REALTIME and try with it?
https://github.com/luads/php-xbase/releases/tag/1.3.2