Hey @SanderAdam,
Does the location point to a folder on the user’s pc? Some things off the top of my head that might be causing this:
- Is a virus scanner running on the machine? It may be trying to index the newly created temp file and block access
- How are the batches being created? Could it be that this somehow results in a temp file that has the same name as an already existing one?
- Perhaps the component is trying to move on to the next batch of files and trying to delete the old one while the upload is still in progress?
This is what comes to mind. We would need to see further logs to accurately detemine what is happening here. Let me know if this helped or if you found what is causing this issue.
Hey @SanderAdam,
Does the location point to a folder on the user’s pc? Some things off the top of my head that might be causing this:
- Is a virus scanner running on the machine? It may be trying to index the newly created temp file and block access
- How are the batches being created? Could it be that this somehow results in a temp file that has the same name as an already existing one?
- Perhaps the component is trying to move on to the next batch of files and trying to delete the old one while the upload is still in progress?
This is what comes to mind. We would need to see further logs to accurately detemine what is happening here. Let me know if this helped or if you found what is causing this issue.
Hey @Peter Verwijs,
The cache folder by Indicium does not make a lot of sense, as we directly upload it to the database.
- The pc we test this on do not have a virus scanner other than Windows Defender.
- The batches are uploaded via a custom component, that component does a request to Indicium so the files can be put in the table they're needed in, I don't see how this upload process can cause Indicium to trip over such a file.
- This could be possible, but since we directly upload them to a table in our Thinkwise software, there is no necessity for temporary files.
And as for now this is the only log I can dig up when I try my best to reproduce this issue, as it is only reproducable in our Azure environments, which is our test environment. When it happens, only this error pops up and nothing else.
Hey @SanderAdam ,
Since you are making a custom component you might have already done so but I’d still like to ask you to read the following docs:
Basically when sending a single request Indicium still treats it as if the resource staging mechanism is being used.
E.g. in the case of a single request POST it will:
- Create a new a new “resource”
- Patch each value into that resource
- Finally commit it to the database
With files this does have the side effect that it has to temporarily write the one that you are POSTing to Indicium’s local file cache before moving it to the actual file storage location when the commit happens at the end.
As for the error itself, you mention you are using Azure. I assume an Azure Web App? If so then e.g. when you are also scaling Indicium horizontally the underlying file system does get shared between instances I think. And thus the cache folder as well.
So perhaps, if the volume of requests is large enough, two instances might decide to try and use the same random file name or something and one of them wins over the other.
If most of what I assumed above is true for your case then I think it would be better to file a ticket in TCP with more information on how you are hosting and calling Indicium from your component.
