Created attachment 1016 [details]
Blankish error message

1) You can't save the project - to FAT32 - or to a.n.other NTFS drive
2) If you try to File >Exit
a) compaction starts
b) briefly the AUP3 rises to the bump-stop limit 4,194,xxx
c) Then it AUP3 reduces to 626,352 (which is what one expects for 30 mins stereo)
d) You get the Blue-Circle-Of-Death for a long time
e) eventually it closes

3) Observe a 2,514,009 WAL and a 320 SHM are left behind cluttering the drive up
4) Relaunch Audacity
5) Open the project
6) Observe: Blue-Circle-Of-Death for a long time
7)  Observe eventually - a fairly blankish error message - no "?" help button either (see attachment)

This is a close cousin of Bug #2575

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:
https://alphamanual.audacityteam.org/man/Error:_Unsuitable_drive#Exporting_to_a_FAT_formatted_drive

See bug 2596 just for the symptom of a blank error message.  That is not special to the use of FAT file systems.  There should be some text in the message box.

Downgraded to P3

Added a Release Note and a workaround

I discussed this with the RM 

As we now have a proper error message shown when disk-full through editing occurs we can now mark this as DEVEL FIX MADE - which I have done

Created attachment 1037 [details]
Wrong/poor error message

Testing on W10 with Audacity 3.0.0 4cb9bb1

I now no longer get the disk with my initial report in Comment #0 which was a proper disk-full message.

Now I am getting 
>File error
>Audacity failed to read from a file in H:
(see attachment)

The help button on that error message links to https://alphamanual.audacityteam.org/man/Error:_Opening_or_reading_file

This is totally meaningless to the user who is actually facing a full-FAT bump-stop as they are about to exceed the 4GB FAT single file limit.  This error message may be White-box technically accurate as far as Audacity's underpinnings go - but it will be baffling and meaningless and no help at all to the user.

Accordingly I am REOPENing this and upgrading it to P1

Created attachment 1038 [details]
garbage temp file left behind on Saving and closing

Testing on W10 with Audacity 3.0.0 4cb9bb1

At Step 7 I was able to successfully Save the Project and Exit Audacity.

BUT I was left with a 7.2MB garbage temp file from the compaction
>fattest.uap3_compact_temp

The WAL and SHM files were properly removed.

I was able to relaunch and reopen the project successfully - but I got a false recovery on opening it (note that no recovery was offered on relaubch)
>Project Recovered
>This project was not saved properly the
>last time Audacity ran
>It has been recovered to the last snapshot

(In reply to Peter Sampson from comment #8)
If I then 
1) Close Audacity 
2) Relaunch
3) reopen the project
4) Observe: it open *much* quicker
5) Observe: nor faux-recovery message on reopening

And note that the 7.23MB fattest.uap3_compact_temp is still hanging around wasting space on the user's drive

I realized that in my previous test I only had 7GB free which made me wonder if in the test on Comment #7 I was actually running out of space for the combined AUP3, WAL and SHM files.

So I retested but freed up a lot more space on the DAT USB stick - 18GB

Withe the final effect
1) Audacity stopped with disk full error message
2) After  OKing that - somewhat surprisingly the effect completed
3) AUP3 was 4.194 bytes (i.e. 4GB) WAL is 1.9GB

4) I can the Save and exit (note that I didn't follow the advice from the disk-full error message (it disappeared as the last effect completed)
5) AUP3 still 4.194 bytes (i.e. 4GB) WAL is 1.9GB

6) relaunch and reopen
7) Observe: error message
>Error opening project


So although this time I get the "proper" disk-full error message

a) The effect should NOT continue after the disk-full

b) the use case in Comment #7 with just 7GB free space still should not have the can't read file error.

-----------------------------------------------------

Aside:  These tests are so painfully slow and time-consuming I find it really hard to believe that any real-life user will be user a FAT drive for a live project.  So I still think we'd be better off just blocking FAT drives for Audacity Unitary Projects.

(In reply to Peter Sampson from comment #10)
> Aside:  These tests are so painfully slow and time-consuming I find it
> really hard to believe that any real-life user will be user a FAT drive for
> a live project.  So I still think we'd be better off just blocking FAT
> drives for Audacity Unitary Projects.

This could be done...just say the word.

(In reply to Leland Lucius from comment #11)
Leland, as this is a P1 (and rightly so in my opinion) then there is no option, it has to be fixed as with P1 status it blocks release.

(In reply to Peter Sampson from comment #12)
> (In reply to Leland Lucius from comment #11)
> Leland, as this is a P1 (and rightly so in my opinion) then there is no
> option, it has to be fixed as with P1 status it blocks release.

What I meant was do you want us to just reject FAT filesystems altogether as you suggested?  Or should I look at finding a way to a better message?

(In reply to Leland Lucius from comment #13)
I think that blocking FAT entirely should be avoided if possible. There appears to be no technical reason why Audacity can't be used with FAT for small projects, and many users only use Audacity for small projects. 

The vast majority of my projects are small, and I also use a FAT32 formatted hdd partition so that I can easily pass data from Win 10 to Linux on my dual boot system. I doubt that I'm unique doing this. However, this is a convenience, not a necessity.

If we disallow FAT, I would expect user complaints about this regression, and I think that such complaints are reasonable.

As Peter wrote in comment #12, it has to be fixed as it has P1 status, so if disallowing FAT is the only practical solution, then we have to disallow FAT.

TL;DR
Disallowing FAT looks like an easy and effective solution. Personally I would prefer a solution that avoids the regression, but I don't think it's worth a huge amount of effort.

Personally I would still, as James and I discussed earlier just block the use of FAT drive for live projects and project Save, Save As and Backup.

They are fine (and great) for Exports - but really not suitable for live projects.  

Remember that most if not all FAT drives will be USB thumb drives now (no FAT formatted system disks these days I'd have thought)so it's not just the 4GB limit but the inherent slowness of USB that makes them unsuitable for live projects.

"we'd be better off just blocking FAT drives for Audacity Unitary Projects."

I think so too.  MOST FAT drives will be slowish USB Fobs.  There are faster external USB hard drives that are FAT formatted, and you can buy extremely fast USB fobs (possibly FAT formatted).  Even so, the 4GB limit will remain a gotcha.   
** As RM, I'm saying let's disable FAT for projects for 3.0.0.  **



More information:
USB fobs can be formatted exFAT, which is sharable with Mac.  Maybe we actually want to detect 'really slow and grotty USB fobs'!!? Something to think about for the future! I think using no FAT to push people to use the fobs for transfer only is good. IF we get complaints, then we can look at more complex solutions.  In 3.0.1, with a space meter, I'd be OK with a new preference 'allow FAT'.  So we have a path forward too.

I agree that  the arguments put forward by Peter and James are reasonable, and I don't have a strong opinion either way.

OK so then let's go ahead and block the use of FAT drives for live projects.
So please. Leland, go ahead and do that.


A) This means that a user cannot open an AUP3 project that is on a FAT drive

B) It also means that that File > Save Project > Save Project  and File > Save Project > Save Project As must be blocked from saving to a FAT drive.

C) It probably makes sense to block using File > Save Project > Backup Project saving to a FAT drive.  If we do allow this then we should probably show a warning to the user telling them they can't reopen from AUP3 on FAT and they'd need to copy it to a non_FAT drive.


Note that for the error message(s) for the blocking FAT drive use there is already an existing Error page in the Manual for the target of the "?" help button:
https://alphamanual.audacityteam.org/man/Error:_Unsuitable_drive
It still needs a bit of tidying up - I will work on that (depends on if we block C as well as A and B).

Though a user could Backup to a non-FAT drive and then copy that drive to a FAT thumb drive for transfer.

(In reply to James Crook from comment #16)
>** As RM, I'm saying let's disable FAT for projects for 3.0.0.  **

We also need to remember that we need to block the use of a FAT/FAT32 drive as a temporary files directory in Directories preferences.

This is sort of funny and apropro...just published today:

https://www.theregister.com/2021/01/04/windows_format_fat32/

I'm working on denying usage of FAT...nearly there.

Fixed in:

https://github.com/audacity/audacity/commit/50f3321

Saving files to FAT filesystems should no longer be possible. But it will still be possible to modify projects already on FAT filesystems. However, a different drive must be selected when saving.

Peter, you were right about FAT filesystems not being detected on OSX. This commit should have fixed that:

https://github.com/audacity/audacity/commit/8e333e1

(In reply to Leland Lucius from comment #21)
Testing on W10 with Audacity 3.0.0 fd774c0

I confirm that this bug as stated is now fine on W10 with Save, Save As and Backup Project blocked for FAT drives (the tests fails at Step 3 trying to save the empty project)- I tested with FAT, FAT32 & exFAT and all are blocked from project saves.

I also tested trying to set the Temporary files directory to be on a FAT drive and that too is now blocked.

There is a minor residual with the content of the error message(s) but I am dealing with that offlist with Leland.


--------------------------------------------------

Later I will be testing the usecase of opening projects (normally older AUP projects) on FAT drives that Leland discussed.  If that turns out to be any form of issue I will raise a new different bug for that

Testing on mac)S 11.1 Big Sur with Audacity 3.0.0 fd774c0

Like Windows the use of FAT and FAT32 are disallowed on the latest 3.0.0 UP alpha, now blocked by the general trap inhibiting the use of FAT drives for any form of project save.

So as this bug as-stated works on Mac I shall mark this on Mac.

----------------------------------------------------------------

However as with Bug #2603 and Bug #2604 there is a residual wherevy sxFAT drives are "allowed" for project use on Mac - but the progress through the steps to reproduce is interminably slow.

Accordingly I really think that we should block exFAT use on Mac as well as FAT and FAT32 (and that keeps us consistent with Windows).  I shal raise a new bug for this.

Residual logged as P2 Bug #2620 Mac: exFAT drives are allowed for use but can be very slow

(In reply to Leland Lucius from comment #21)
> But it will still be possible to modify projects already on FAT filesystems.

I tested making AUP projects and storing those on FAT/FAT32 and exFAT drives.

a) I could successfully open (and import) the projects on 3.0.0 and manipulate them.  
b) I could not save back to FAT/FA32 as expected.  
c) On Mac I could save back to exFAT but not so on Windows.

This is a useful bonus feature - I will need to change the error page in the Manual.

(In reply to Leland Lucius from comment #21)
On Linux (Xubuntu 18.04) with a release build of 69a9866, I am still able to save a project onto a 64MB FAT16 or FAT32 thumb drive.

After saving the project, I am able to eject the drive, reattach it, and open the project.

(In reply to Steve Daulton from comment #26)
If I save a project on a FAT drive, and then continue to work on the project, I eventually get an error:

"Audacity failed to read from a file in <path to FAT drive>"

If I then try to save the project (which saved successfully previously), I get the error:

"Projects cannot be saved on FAT drives.
For tips on suitable drives, click the help button"

This message is confusing as I was initially able to save the project. I just can't save again after modifying the saved project.

(In reply to Steve Daulton from comment #27)
On the basis of Steve's test I'm REOPENING this bug for the residual which is Linux-only.


I retested on Win and Mac with Audacity 3.0.0 69a9866 
to ensure that FAT and FAT42 are still blocked for making saves (including initial saves) - thus this bug as stated in the title and steps can no longer arise on those two platforms.

(In reply to Steve Daulton from comment #27)
Residual logged as P1 Bug #2628
>Linux: FAT/FAT32 drives can wrongly have projects saved to them

a} to give clearer bug description and steps

b) to enable us to close this for Win and Mac