Bugzilla – Bug 120
Linux/Mac: Entering "\" in file name when saving projects disallows the save.
Last modified: 2020-08-22 08:45:59 UTC
* On Linux and Mac, "\" is legal, so should always be accepted. * On Windows (XP), "\" should (I think) trigger a standard OS warning "Path does not exist". Note that entering "/" does trigger a standard OS warning "the above file name is invalid". * File > Save Project As gives the same "disk full" message when entering "\", but does permit access afterwards to correct the problem.
Devel-Fixed in Rev:10928 If I've understood the bug correctly the issue was a completely misleading error dialog. I've added a new one that is tested for sooner and that suggests creating the directory.
James, looks fine on Win, though it wasn't an issue on Win7 as the OS gave a decent "Path does not exist. Check the path and try again." error (and still does after the fix). I assume this is because we use the native Win 7 file filtering on that platform? Reopened for OS X and Linux because as per the Description , "\" is legal as a path separator on those platforms (i.e. exporting "test\file.wav" works, so "test\file.aup" should do so too).
According to http://en.wikipedia.org/wiki/Path_%28computing%29 '\' is not a path separator under Unix like OS's. So "somepath/test\file.wav" has path "somepath" and filename "test\file.wav" where the '\' is 'just an ordinary character' in the filename. You're not seeing a new directory "somepath/test" being created. From your description I am suspecting wxPathOnly(), which gets the path (to check if the directory exists) is not correct in wxWidgets, and on Linux behaves exactly as on Windows. I substituted a more sophisticated function FileName::GetPath(), which I have very high confidence detects the platform correctly like so: At line 3047 in AudacityProject::Save( // We suspect that wxWidget's wxPathOnly is Windows specific and incorrectly // treats '\' the same as '/' under Linux. So we comment it out // wxString projName = wxFileNameFromPath(project) + wxT("_data"); // wxString projPath = wxPathOnly(project); // ...and try this approach instead. wxFileName filenameAsClass( project ); wxString projPath = filenameAsClass.GetPath(); wxString projName = filenameAsClass.GetFullName() + wxT("_data"); I checked this in, however, I had to revert the change, as Audacity uses wxPathOnly in many many places, and if this works we would need to change every one because they all have to match. Before we can proceed we need a Linux dev to verify that wxPathOnly is incorrect. Then we either create an audPathOnly and audFileNameFromPath and globally replace, OR we add code to disallow '\'. Notes: If I'm right, this will also fix a P6 buglet that "test\project.aup" would previously show as "project" in the title bar in Linux. It should now show as "test\project". There is an argument for disallowing '\' in a filename under linux, and always treating it as '/'. Files with '\' in the name will not be shareable with windows users. A counter argument is that users should have freedom to use what is allowed.
(In reply to comment #3) Sorry for the faux pas in comment 2, too many bugs and e-mails. I think one use case for "\" in project names is that some people have projects for individual album tracks where the "\" is very handy - they can already use the "\" for any files exported from the project. > If I'm right, this will also fix a P6 buglet that "test\project.aup" would > previously show as "project" in the title bar in Linux. It should now show as > "test\project". I noticed on Linux that if I save "test.aup", rename the .aup to "test\file.aup" and the _data folder to "test\file_data", then change the projname in the .aup to "test\file_data", Audacity does not find the _data folder when opening the project, so we'll have to be sure that's covered by the fix. > There is an argument for disallowing '\' in a filename under linux, and always > treating it as '/'. Files with '\' in the name will not be shareable with > windows users. A counter argument is that users should have freedom to use > what is allowed. I think the counter argument would have to win. To ensure Windows users could open projects created on Linux and Mac without modification you would also have to disallow : * ? " < > | (":" is illegal in file and folder names on Mac, but not Linux).
I confirm this is still the case woth 2.2.0 and 2.2.1 RC1
Testing on macOS 10.15.6 with Audacity 3.0.0 25ddfc7 This now works saving with 3.0.0 alpha on Mac - I saved a project called test\file.aup3 But the residual issue is that I cannoy re-open the saved project. I get the error: >Error Openeing File >Could not open >file :Users:petersampson:Desktop:test\file.aup3
This is a very close cousin of Bug #1441 and looks like distant cousin of Bug #666
Testing on macOS 10.15.6 with Audacity 3.0.0 93c5525 This now works on Mac project files can be saved with either a "\" or a "/" in their name (but see Bug #1441).
Works on Linux.
On Windows you get a sensible error message when you try to do this.