Renaming folders on Linux


#1

I just uploaded a ~300GB folder by copying it my Drive’s local folder.
Besides the fact that it took almost a full day just to parse and upload the folder structure and an extra 2.5 days to upload the rest which seems way too long, I had to rename the top level folder I had just uploaded, I did so in my file system.

I’m using Insync 1.3.12 on Ubuntu 14.04 and the app indicator icon just went in sync mode but nothing is going on. If I look at my Drive using a browser the folder has now disappeared from my Drive and all its files have been moved to Trash by Insync (it took ~1.5 hours just to delete). In the trash I see the folder with the old name, but in my Drive the new one hasn’t arrived yet.
(Thinking I could stop the command I restored the trashed folder with the old name from the web interface but no files were inside, I Ctrl+Zed my way out of that and it doesen’t seem to have started a whole new 3.5 day thread yet)

The only reason it could be taking so long I imagine, is that Insync, for some reason, deletes the files from Drive and re-uploads them to a folder with the new name. Which does not make sense to me since https://developers.google.com/drive/v2/reference/files/patch

Questions:
Where are my files?
Do I have to wait for 3.5 days before I use / can share my files with my team because it’s re-uploading everything?
(Although this started at 10:03AM and it’s now noon and sync indicator is still on but nothing seems to be happening)
If this is normal behavior do you think it’s reasonable?
If it’s not normal behavior what went wrong?

Would Insync do the inverse as well if I rename a folder in the web interface?, i.e. Would it re-download the whole folder and trash the original one in the local file system?

UPDATE: I tested on the same version of Insync in an Ubuntu 16.04 same user and rename seems to be properly implemented, I don’t understand…
UPDATE2: Scratch that, I cannot see indications of renaming of folders on web activity pane, only of files, but this is true for renaming from web OR local FS… I can see Insync indication of both folder and file name change though.
For what I understand a Folder is just a file with no extension so it should have a folder.title that can be patched using the link of the REST API v2/3 I mentioned earlier…
UPDATE3: I restored in the web interface the folder with the old name, renamed it with insync paused, once it was done (note: it takes a long time from the web interface also to modify stuff on a large folder) I released the kraken, I mean, I released the pausing of the sync, and allowed insync to rescan and check each file of the pretty large and intrincated tree struct. It took some time but way less than the whole re-upload thing.

CONCLUSION: If enough time passes the problem solves itself… Although I don’t think its a viable support policy for a tech company, there is really no excuse not to have this documented somewhere and easily accessible to users (which in this case are actually paying costumers).


#2

Tagging our engineer @lpugoy and he will get back to you.


#3

@Niccolo_Bonacchi: Apologies for not replying sooner. Please send your logs to support@insynchq.com for investigation: How to find the log files. It is not normal behavior though to delete a folder and re-upload or re-download it when it is renamed. Hopefully I can find some clues in the logs to what happened.


#4

Had a similar - and terrible! - experience. Why do a simple renaming mess with everything?


#5

In my case I actually swapped names of two folders, and decided that it didn’t make sense and swapped back. So I made A -> tmp, B -> A, tmp -> B; and later its reverse. It is pretty annoying.


#6

Hi! If you haven’t, kindly send your log files to support@insynchq.com with the link to this post. Our engineer will take a look at it so we can prevent this from happening again. Sorry for the trouble! :frowning:


#7

It is 2019 and this is still happening and there are several open and unsolved related issues.


I just lost a lot of data because of a similar problem…


#8

Hi @Francio_Rodrigues

I’m really sorry for all the hassle and disruption that the data loss due that occurred due to this bug.

Please be assured that we’re on top of this. My colleague @miamoran has already replied to your email and will be communicating with you regarding this issue.