Bugzilla – Bug 2575
Recording to a FAT32 drive fails at around 3h20m with no error message and project corrupted
Last modified: 2021-01-04 10:02:17 UTC
Created attachment 1014 [details] Corrupted project Recording to a FAT32 drive fails at around 3h20s with no error message and project corrupted. FAT/FAT32 has a single file limit of 4GB we may struggle with longer projects - something that did not and could not happen with piles of files. My calculations indicated that the 4GB limit should be hit between 3h22m and 3h23m for a stereo recording with default Audacity settings. I used a USB stick with 26.7GB of free space - as I started recording Audacity told me I had 22H36m left The recording progressed nicely and I left it unattended (went to bed). I woke in the morning to find that 1) the project had just stopped at 4h20m26s 2) there was no error message 3) I could not save the project to the Fat32 drive - disk full error 4) I couldn't save it to my NTFS C: drive (desktop) - also gave disk full error 5) Zooming out showed a very corrupt project with just a few minutes at the end. Most users would probably give up here - but I persisted closing Audacity relaunching and opening the file file the FAT32 and succeeded in saving it to the C: drive desktop. On opening it from there I found a mostly complete project with a 9 minute gap part way through the project. Now I had a strong hunch that if we fix our old friend Bug #2546 and make Audacity stop on Yellow that may also cure this, but sadly this was not the case
This is a close cousin of Bug #2576
Following QA/RM discussions this is likely to be fixed by inhibiting the use of FAT formatted drives with Audacity 3.0.0 and later. An error page has already been provided in the Manual as a target for the "?" help message in the error trap that will be provided.
(In reply to Peter Sampson from comment #2) >An error page has already been provided in the Manual as a target for >the "?" help message in the error trap that will be provided: https://alphamanual.audacityteam.org/man/Error:_Unsuitable_drive#Exporting_to_a_FAT_formatted_drive
Following a request from Paul (as presumably he thinks this now works die to other changes) I spent most of yesterday retesting this with Fat drives on my PC and my Mac. I tested recording to exhaustion and applying effects to exhaustion with a shorter project on USB sticks with 13GB free space. Details of the tests will follow in additional comments In all 4 use cases a) I got a disk-full error message b) the project was salvaged by following the instructions in the page in the Manual linked to from the "?" help button Accordingly I shall mark this bug itself, as stated, as OK on Win and Mac A couple of residuals: 1) Following the help requires that the user realizes that they are on a FAT drive as the way to deal with this FAT issue is to Save Project to a non-FAT disk. It will not work if: a) the user tries to free up space on the FAT drive (its the 4GB filesize limit that's the problem) b) tries to copy the AUP3 and WAL (and SHM on Windows) files to a non-FAT drive with a file manager - the manually copied project fails to open. This is because we are using the generic disk-full error message to trap this, In fact this is not really a disk-full situation but a special use-case with FAT file size being breached. If we wanted to be more watertight here we could trap this with a different error message and create a new help page in the Manual for FAT-full to be linked to from that error message. For this fringe use-case I'm not convinced it's worth that effort. 2) Remaining recording time is shown at the start of recording as: a) accurately on Mac with regard to the 4GB limit as 3h 23m b) but on Windows it shows incorrectly as 11h 02m - which, of course, is based on the 13GB of free space I had on the FAT USB stick This is more serious as it can badly mislead the user on Windows and could could to an important recording being unexpectedly curtailed. Accordingly I shall be logging this as a fresh P3 (marginal P2) bug later today.
Use Cases 1&2 recording onto a FAT/FAT32 drive on Win/Mac 1) select a FAT/FAT32 clip drive with at least 10GB (remember the WAL file can occupy large space too), 2) Launch Audacity 3) Save Project to the FAT/FAT32 drive 4) Observe: Status bar message is correct on Mac incorrect on Windows 5) Wait for 3 hours 20 minutes ... 6) Observe: at 3h20m26s on W10 FAT (and at 3h23m07) on FAT32 on Mac our normal disk-full error message. 7) Observe: the message is =misleading as the drive is not full, rather the $GB limit has been reached 8) Click in the "?" help button to go to the Manual 9) Carefully realize that you are on a FAT drive and follow the FAT instructions on that page. 10) Following those instructions: File>Save Project to a non-FAT drive (say system disk). 11) Observe: Project saves to the new drive 12) File >Exit Audacity 13) relaunch Audacity and open the project from Step 10 14) Observe: project opens properly and further editing/recording can be accomplished. 15) with your file manager examine the FAT/FAT32 drive 16) Observe: residual AUP3, WAL (and SHM on Windows) occupying space. The project cannot be opened from this AUP3/WAL so this is just wasted space that the user must recover manually with their file manager.
Use Cases 3&4 applying 3 edits to a one hour stereo chirp on a FAT32 drive with 13GB free space on Win and Mac. Her I used the FAT32 for both platforms as it is USB3 and about 4 times faster than my older USB2 FAT drive. 1) select a FAT/FAT32 clip drive with at least 10GB (remember the WAL file can occupy large space too), 2) Launch Audacity 3) Save Project to the FAT/FAT32 drive 4) Open your file manager (and keep it open) to observe project file sizes 5) add new stereo track 6) generate Chirp 7) Observe: Win AUP3 1.256GB/WAL 0.64GB - Mac AUP3 1.29GB/WAL 1.29GB 8) apply Wahwah effect 9) Observe effect dialog completes - but it takes a while - and then closes 10) Observe: waveform remains as the unchanged chirp 11) wait several seconds ~10-20 12) Observe: eventually the waveform updates 13) Examine the project file sizes 14) Observe the AUP3 file still remains at 1.256/1.29GB (and WAL 1.256GB/1.29GB) 15) Wait ~40-45 seconds 16) Observe: eventually the reported size of the AUP3 increases 17) Observe: Win AUP3 2.512GB/WAL 1.256GB - Mac AUP3 2.57GB/WAL 1.29GB 18) apply Echo effect 19) Observe effect dialog completes - but it takes a while - and then closes 20) Observe: waveform remains as the unchanged Wahwah-ed chirp 21) wait several seconds ~10-20 22) Observe: eventually the waveform updates 23) Examine the project file sizes 24) Observe the AUP3 file still remains at 2.512/2.57GB (and WAL 1.256GB/1.29GB) 25) Wait ~40-45 seconds 26) Observe: eventually the reported size of the AUP3 increases 27) Observe: Win AUP3 3.768GB/WAL 1.256GB - Mac AUP3 3.86GB/WAL 1.29GB 28) apply Reverse effect 29) Observe: after a longish while you get the normal disk-fill error message 30) Observe: the message is =misleading as the drive is not full, rather the 4GB limit has been reached 31) Click in the "?" help button to go to the Manual 32) Carefully realize that you are on a FAT drive and follow the FAT instructions on that page. 33) Following those instructions: File>Save Project to a non-FAT drive (say system disk). 34) Observe: for a fair while - Blue-Circle-of-Death on W10 or Spinning Beachball-of-Death on Mac 35) Observe: EVENTUALLY the Project saves to the new drive 36) File >Exit Audacity 37) relaunch Audacity and open the project from Step 10 38) Observe: project opens properly and further editing/recording can be accomplished. ----------------------------------------------------------------- The interregnum at steps 13-16 and 23-17 are interesting. I am presuming that this is the slow copying of data on the FAT USB stick from the WAL to the AUP3 (on normal fast disks this is un-noticebale as it's relatively quick). The really fascinating thing is that Audacity allows you to continue with further edits while the AUP3 is still being updated from the previous edit. This make me worry (in a thought-experiment way) for the stability/fragility of AUP3 files on a FAT drive.
Although this bug is not flagged as "Must test all OS" and thus we could just close it on the basis of my Win and Mac tests - I think it's probably better if we can see Linux tests of this too. I cannot do that as I have no Linux engine. Steve, I believe, had not suitable FAT drive big enough for this test. Therefore I am appealing to others with Linux platforms and a suitable FAT drive to come forward and test this on Linux. The reason I supplied the detailed steps in Comment #5 and Comment #6 was to facilitate such Linux testing with clear steps.
General Observations As you can guess fro the tests I spent a LOT of time on this yesterday (the 3-effects test was long in itself but I repeated it a few times to ensure accuracy). 1) A FAT/FAT32 drive is adequate and responsive enough for recording (subject to the 4GB 3h20m limit). 1.1) While the recordings were taking place I was ding other stuff on both machines. The W10 PC was fine, but the Mac did produce some dropouts throughout - I'll post an image later). 2) Editing on a FAT/FAT32 drive can be painfully slow - most users would give up, I guess. 3) saving a project on (or from) a FAT/FAT32 drive can be painfully slow with Blue-Circle-of-Death on W10 or Spinning Beachball-of-Death on Mac (and this is not good - we never like seeing those in Audacity. 4) Working with a one hour stereo project on a FAT/FAT32 drive does not give you much headroom for editing. Summary ------- I stand by the conclusion that James and I came to in Comment #2 in thinking that fundamentally FAT drives are ill-suited for use in Audacity. I, personally, would like to see the use of FAT drives for project files dropped. I know that there are others that disagree and insist that we should not place such a restriction - but I, personally, do not agree with that position. With FAT we are basically talking about external (normally USB) drives - it's been a very long time since any system drives were FAT formatted, for example Microsoft moved to NTFS for the now-ancient Windows NT. I think that it's the USB (including USB3) that provides the sloth rather than the FAT formatting per se, but I'm guessing it's pretty unusual to have a secondary onboard disk that is FAT formatted. I could change my HP Envy that way if I wanted too (256 NTFS SSD plus 1TB NTFS spinning metal disk) but I'd be pretty stupid to do so!
Created attachment 1028 [details] FAT dropouts on Mac As discussed in Comment #8 These are the FAT dropouts on I got when recording on Mac to a FAT32 USB stick with 13GB free space.
Works for me on Linux.
