File Copy throws error 6007 but file does exist

I am cropping a file with the Image Processor which is then stored in the tmpimages directory. According to Mark’s advice I copy it to another directory to rename it and do other things with it. Sometimes the copy does not work and the above error is thrown. As a workaround I added timers (up to two seconds) to give the process more time to store the file. Sometimes it works, sometimes not. Even with the same input file. So, the error is not systematic, not a problem with the logic as such. I added a routine (repeat while) that checks if the directory listing contains the expected file. And, even if the listing confirms the existence of the file the file copy routine sometimes throws an error.

Result of the crop command:
image

Result of the directory listing for this file pattern:
image

The copy request (exactly the same structure as all other copy commands before):

But, the result of this copy request is:

I have no idea where else to look. What am I missing here? I am grateful for your advice.

As I see, your app is placed in EU zone.
Provide the app id and the steps (one by one) which will lead to the error. It would be really helpful if we are are able to reproduce the problem in your app.

AppId: A2090C1B-936C-A876-FF32-277A55A60700
As said, it is not systematic and happens not at the same step with the same picture.

Use the Page testImageProcessor and press the Upload File Button. Select a picture with at least width and height of 300 px. You can find the Logic in On Upload Success. The Console Log shows you the you the long URL of the cropped piece and the entry in the directory listing of this particular file.

Wait for the error and switch to the Network Tab in Chrome.

Let me know if you need more information.

I understood, but the possibility is still present. So I decided that if I do the same steps several times I can stuck with the same problem.

I’ve tried to play directly with the image processor service. It works fine.
I didn’t find any error in logs. Could it be the problem is within the page logic?

It is the copy command not the ImageProcessor.

Are these statement correct?

  • you are copy the image from the directory where it was saved previously by ImageProcessor to another dir, right?

  • And the code do this just right after the ImageProcessor’s return ?

  • All these logic performed in the cloud code?

  • yes
  • no, I wait for the successful response of the directory Listing
  • no, on Upload Success Event

@oleg-vyalyh any idea?

Hello @Jorg_Beyer,

We already have the internal ticket BKNDLSS-29511 (Sticky sessions in Backendless). After it is done your issue should be fixed automatically. I’ve attached a link of this topic to the ticket, so we’ll notify you as soon as it is done.

Regards,
Olha

Jörg Beyer, why did you perform listing?
It’s quite heavy operation and in a architecture with several servers (and we have this) it doesn’t matter much, because the next api call can pass through different machine.
The Upload Success Event already says that the operation is completed and the file have to be on it’s place.

Hello @Jorg_Beyer !
I made the changes, please check how it works now.

I have used it and it is quite stable. But without the directory listing routine as the file copy confirmation routine it is not reliable.

Hi @Jorg_Beyer ,

With our recent changes you do not need to do listing operation after file copy since all requests to the file system from one handler/client will go to the same server.

Regards, Andriy

I would love to give you a positive feedback, but here on my end I need to perform this wait routine. Otherwise it is still not reliable. This workaround is fine by me. No further changes necessary.

Are you retrieving “The specified resource was not found” error again?

yes

I see what the problem is. We plan to make some architectural changes in the future, which will either completely remove, or at least significantly reduce the lag between file system synchronization. So far, that’s the only way, unfortunately. We’ll let you know when these changes are ready.

Regards,
Stanislaw