Bug 1507 – Project may be overwritten by new project without warning

••• Introduction •••
••• Keywords •••

Audacity 3.0.3 development began 19th April 2021

Audacity Bugzilla

Bug 1507 - Project may be overwritten by new project without warning


Summary:	Project may be overwritten by new project without warning

Status:	RESOLVED QUICKFIXED

Product:	Audacity
Classification:	Unclassified
Component:	Formats
Version:	2.1.3
Hardware:	Per OS All

Importance:	P1 Repeatable
Assigned To:	Default Assignee for New Bugs

URL:	http://forum.audacityteam.org/viewtop...
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2016-09-05 07:25 UTC by Steve Daulton
Modified:	2018-08-20 11:45 UTC (History)
CC List:	7 users (show)

See Also:
Steps To Reproduce:	1) Create and save a project as "test1.aup" (Just an example. The actual name is unimportant) 2) Create an audio file in the same directory as the project with the same name as the project. For this example, "test1.wav". 3) Restart Audacity and import the audio file "test1.wav" 4) Save (or Save As) "test1.aup" (the name is already selected by default). The original "test1.aup" project is overwritten by the new project without warning.
Release Note:	GROUP: Projects * '''If you import a file into an empty project where the file has the same name as an existing project''' then save the project to the same directory without changing the name, the existing project will be overwritten without warning,
First Git SHA:
Group:	---
Workaround:
Closed:	2018-08-20 00:00:00

Flags:	petersampsonaudacity: Test‑OK‑Win+ petersampsonaudacity: Test‑OK‑Mac+ gale: Test‑OK‑Lin+

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Steve Daulton 2016-09-05 07:25:00 UTC

If a file is imported into new project, and the file is in the same director as a project with the same name, then saving the project with the default name and location will overwrite to original project without warning.

Gale has stated that he considers this to be a blocking issue, so given an initial rating of P2.

Following the steps to reproduce, the "correct" behaviour would be the warning:
"Error Saving Project"
"The project was not saved because the file name provided would overwrite another project.\nPlease try again and select an original name."

The error message is not triggered because Audacity thinks that it is the original (old) project that is being saved (because the project name and path of the old and new projects are identical).

Comment 1 Steve Daulton 2016-09-05 07:34:30 UTC

Pull request for fix: https://github.com/audacity/audacity/pull/162

Comment 2 Gale Andrews 2016-09-05 08:23:23 UTC

Thanks, Steve. Yes I would want to block on this so set as P1 (unless fixing it is problematic in some way). We have a real life case (see URL) where a user lost a recording which was the original project content. 

I agree given we don't allow overwriting of existing projects unless the project is already open, refusing overwrite should be the response to this case.

Comment 3 James Crook 2016-09-08 13:00:20 UTC

DEVEL - FIX MADE

https://github.com/audacity/audacity/commit/bf06b0485fa6886f63c21e6c8cab13b8e585a894

Fix in comment #1 was along the right lines, but would have continued to reject a Save of a file initially loaded as an import but later saved with SaveAs.  Every place where mFileName was written to needed to be reviewed to see if the flag indicating valid/invalid aup name should change or not.

Comment 4 Peter Sampson 2016-09-09 12:46:06 UTC

(In reply to James Crook from comment #3)
Testing on dcaba6e 08Sep16 on W10 and Mac El Capitan

On both platforms wne I follow the Steps to reproduce an error message is thrown up and the overwrite Save is inhibited.

Comment 5 Gale Andrews 2016-09-09 14:06:18 UTC

(In reply to James Crook from comment #3)
> Fix in comment #1 was along the right lines, but would have continued 
> to reject a Save of a file initially loaded as an import but later 
> saved with SaveAs.
Thanks, James. 

I tested on Linux including that scenario above where the project was saved from an import then reopened, then the file of same name imported, where the save should be allowed.

Also on Windows in Step 4, I emptied the offered file name then selected the same AUP file instead, and another case, emptied the name and typed it in, including typing the name with alternative case. The save was always rejected. So it seems OK to me.

Comment 6 James Crook 2016-09-09 14:12:10 UTC

Thanks Gale.  Hadn't thought of the (potential) for a case sensitivity issue.  If the code had been implemented with string comparisons, that would have been a likely bug.