So you are getting an SQLITE Error Code 13=SQLITE_FULL.
The SQLITE_FULL result code indicates that a write could not complete because the disk is full. Note that this error can occur when trying to write information into the main database file, or it can also occur when writing into temporary disk files.
Sometimes applications encounter this error even though there is an abundance of primary disk space because the error occurs when writing into temporary disk files on a system where temporary files are stored on a separate partition with much less space that the primary disk.
I have not seen this error reported before in the forum, so it is likely that you can correct the issue just by finding a little bit more space somewhere.
If you are still having this issue tomorrow and you want me to look at your project, post back.
I experience the same issue. I work back and fort between two system: A Big Sur (11.3 20E232) Apple system and a Windows 10 at another place. Latest Audacity on both (3.1.3). Before I have successfully worked on the same files thanks to Google Drive but now I get this error instead. I am now “streaming” Google drive (as they call it) and I understand there are lot of temp files working in the background. Maybe It has to do something with that. I would really like this to work; feel like my hands are a little bit tied here!
Another issue with the new Google Drive is that the virtual drives it creates are only FAT32 with no possibilities to change. Even if the data it resides on is of another format. Audacity won’t let me open from a FAT-drive so I have to copy the file to a local physical disc to work with it and then copy it back to drive, or updating the file. It still doesn’t solve the initial problem.
On the Mac this is not the case as the virtual drive is NTFS (mounted through SMB). This might, or might not, also have something to do with it.
Just a little extra info complementing my post above: I have loads of space on both systems — even on the Google Drive (theoretically at least). Uploading zipped file and working on extracted file back at the mac produced the samt result.
Please do not work directly on a project held on a networked or cloud drive. Most users who do this end up with a corrupted .aup3 project.
If you care to zip up your .aup3 project file then upload it to a public file sharing service, I’ll take a look at it. Unfortunately, I am quite busy for the next few days so I cannot say when I can get to it.
I did copy the un-openable file from my Mac based Google Drive to the local drive on the same Mac (“natively” sts) and then it opened without a hitch! Well, i guess that’s good somehow and this might be a working, although quite cumbersome, solution but it sort of defeats the whole purpose of a having cloud base, always-accessible-wherever-I-am drive, especially since I can’t even save directly to the drive while I’m on Windows (because it poses as a FAT-drive then). I don’t know if it’s more of a Google issue than an Audacity one but in this modern era of cloud based work I propose this should be straightened out. I haven’t personally encountered any other application with similar cloud-related problems (though I guess there would be some.) Please chip in on this in case I’m maybe just a lone weirdo with some very strange ways of working…
So I am going to rephrase my note above to say that I believe many of the reported issues of corrupted projects were born on networked or cloud drives. Other than that, I am going to stick to repairing these projects and let others deal with the whys and wherefores.