File rename delayed until viewed in the Insync GUI

I have reported this bug before but the post got closed and it has never been fixed. Files temporarily disappear from local drive after a rename

I have a Windows program that I wrote myself that renames files that it uses as a database. It expects the rename system call to be synchronous, i.e. when it returns it expects the file to be renamed and reports if it finds it isn’t there under the new name the next time it needs to read it.

If the directory has lots of files in it the rename does not happen until I navigate to the file in the Insync GUI. I then see it appear in front of my eyes and this can be an arbitrary length of time since the system call. I.e. it will never do it locally unless I navigate to it.

There seems to be a threshold in the number of files in folder before the bug happens and then it always happens. This morning a folder of 22 files worked but a folder of 52 files didn’t. Please fix this as it is very annoying. Systems calls that are synchronous cannot be made asynchronous and depend on the GUI, it makes no sense.

Hi @nop_head! Apologies for not getting to a resolution on the original Forums thread, and thank you for re-opening the issue.

Could you please send me your latest logs.db and out.txt files?

Please also specify the following:

  • Original name of the file
  • What the file was renamed to

Thank you!

I did that two years ago. I don’t think any of the bugs I have reported have been fixed.

Hi @nop_head,

I’ve forwarded the logs from last time to our engineers, and have re-opened this case for further investigation. I’ll check with them if the two sets of logs you previously sent would suffice, or if we need a new set for comparison.

To check: were the files open at the time it was renamed? Or is this renaming issue also observed regardless if the files are in use or not?

Thank you!

No the files are not being used, that are just renamed from palmerc_test.scad to something like 026.scad in a folder with 000.scad up to 025.scad already present. They will have been written to some time before, for example 5 minutes.

Once the number gets big enough it will only do the rename of the local file when I view it in the Insync GUI. I can even close my application. It does get renamed on GDrive immediately though.

Not sure what would happen if I shut down my PC or close Insync.I might try that next time it happens.

Thank you for providing more information, @nop_head! I have relayed this to our engineers and will update this thread as soon as I know more.

Hello @nop_head! Could you confirm if you’re using the program (and/or Insync) on multiple machines?

Only one machine at a time. The program I use will not allow me to log into the database from more than PC at a time.

We have two homes and I have one PC in one of them and a few in the other. At the moment I am the home with just one Win11 PC, so only one instance of InSync running and I get the issue.

1 Like

@nop_head Thanks very much for the detailed info on your machine setup. I’ve forwarded this to our engineers so we can continue with the investigation.

@nop_head Thank you for waiting!

Could we ask you to try to replicating it again, with the ff. steps?

  1. Start Insync
  2. Force your program to do the renaming
  3. Assuming the issue happens, browse the folder in the Insync GUI, and wait for the renames to proceed
  4. Wait for the sync to finish (as indicated by a green check beside the renamed file)
  5. Quit Insync and collect logs.db and out.txt files
  6. Send the log files to with the link to this Forums post

Thank you!

It didn’t do it with a fresh start of Insync. I normally have it open permanently. The only time I would close it is when Windows forces a restart.

Hi @nop_head, is it possible for you to try the abovementioned steps? That would help our investigation greatly, as it seems to be happening specific to your setup.

Thank you so much!

I will do it but unless the bug happens I won’t show much. It seems Insync has to be running some time before it will have the problem. Either that or it has to be several renames in short succession as I normally check in a few files around the same time.

I used to check in all the files at the same time, which would involve lots of writes, renames and removals as fast as the OS can do it. I have tried doing them one at a time with a few seconds in between but I still got the problem. The only time I haven’t seen it happen is when I did a fresh start of Insync.

1 Like

Hi @nop_head! Let me relay this to our engineer and I’ll let you know if he has any additional input :slight_smile:

I got the bug again this evening after running InSync for just over a day. I have sent the log files from InSync and the log from my own program and GDrive.

Oddly out.txt seems to only have info from a month ago.

I just relaunched InSync, experienced the bug again and closed it. The time on out.txt changed to the current time and the only change was this line added to the end.

C:\Users\XXXXX\AppData\Roaming\Insync\App\ideskui\ RuntimeWarning: coroutine 'APIFunction.__call__' was never awaited
RuntimeWarning: Enable tracemalloc to get the object allocation traceback

@nop_head I received your logs and responded to your email as well. Thank you for updating this thread to alert us (and other users who might run into a similar issue).

I bought a new Win11 machine and just got the same error again. out.txt was empty but when I quit Insync it got one instance of the “never awaited” error. However it seems each time I open Insync, do nothing and quit it adds another. But I have had the PC a few weeks and must have quit Insync each time it needed to restart for Windows updates. So perhaps the error is just due to the use of the quit button in the Insync GUI and is a red herring.

My program renamed three files within 2 seconds of each other and the second one did not action until I went looking in the Insync GUI and then it appeared.