Thanks for your testing. The purpose of the part file is to be able to overwrite the target file with a single rename at the end. If OC would write directly to the final file, that file could potentially be accessed outside of OC and would see a partially written content. So the idea is to first write the full file and then rename it to quickly overwrite the original one (atomic rename). The partial content thing might depend on the storage type, not sure if GDrive is clever enough to prevent this when not working with part files.
I’m surprised that editing even simple text files in OC don’t properly overwrite the target file. Last time I tested this a few months ago it worked. Either GDrive changed the behavior or some option is missing in the final rename. So maybe you’re right, it could be a bug in GDrive storage impl on the OC side.
If GDrive is clever enough to not expose a partially written file until it is done to the user, then part files could be disabled for GDrive on the storage level (need to look into the code to see how to do this).
Are you able to test with needsPartFile set to false and then upload/overwrite a huge file in GDrive, and while the transfer is happening, download that file off GDrive directly to see if you get a partial file or the old file. Considering that GDrive already has some kind of versioning, it is very likely that it is clever enough. Then based on this information we can look into disabling part files + final rename for GDrive only.