Error saving message

[kozikowski]

Just a note here, when the elves are tying to dig someone out of a problem, nobody is going to crank through that decision tree of safe characters. We can get people out of trouble immediately by invoking the "Universal Safe Character" list. We don't care a wit what you do after that, but if you conform to that list and your problem goes away, then you win.

Our shop has to push files to all three platforms, all ages and versions, and do it with many file transfer programs including manual FTP. We find the Universal List very valuable in addition to not using spaces.

It's bulletproof and bulletproof is good when you're troubleshooting.

Sorry, that's "Bullet Resistant."

Koz

[billw58]

I've seen no issues with autosave, but correct me if I've missed something. Autosave only kicks in automatically if you force quit.

Autosave apparently works with a forward slash in the project name. It is unclear to me where the autosave information is being saved, though. If I save a project with the name "this is a test/file.aup", it saves properly with that name (that is the file name as displayed in the Finder), but the window title is "this is a test:file". If I then wait for the auto-save interval, force quit Audacity then launch it, I get the recovery dialog which offers to recover the project "file - 2010-02-21 10-59-36 N-3". Note that "this is a test" is not part of the auto-save file name. The project is properly recovered, and the window title is "this is a test:file".

. Strangely, AFAIK, the export multiple function does not trap the "/" character as illegal, but it does trap "*" and "?".

Bill, can you remind me, does export multiple go ahead with "/" in a label, or does it give "cannot export"? On Windows, the "/" character properly triggers the export multiple "not a legal filename" dialogue.

If I create a label "label/test" then do an Export Multiple I do not get the illegal character dialog, and the export fails with "Cannot export audio to /Volumes/Hard Disk/Export folder/label/test.aiff". We've seen this before on the forum with Mac users transcribing LPs - the usual way of listing a medley on the sleeve is with the forward slash character and users blithely go ahead to use it.
If I change the label to "labeltest" it successfully exports.

So on Mac the project save versus export behaviours are opposite - in Save Project backslash generates an unhelpful error but forward slash works, in Export Multiple backslash works and forward slash generates an unhelpful error.

What's really wanted to my mind is for system-illegal characters (customised per the three platforms) to go to essentially the same dialogue, similar to the existing export multiple illegal filename dialogue. Anyway, I can raise bugs for the two specifics.
Gale

Yes, that would probably be optimum. But note that going through the Mac save dialog apparently takes care of the forward-slash issue, whereas bypassing the save dialog (as in Export Multiple) generates an error.

Finally, if I change the label name to "label:test" (an illegal filename on Mac) the Export Multiple succeeds, and the saved file is named "label/test". The substitution of colon for forward-slash (and vice versa) appears to happen at a deeper level in the Mac OS.

-- Bill

[Gale Andrews]

when the elves are tying to dig someone out of a problem, nobody is going to crank through that decision tree of safe characters. We can get people out of trouble immediately by invoking the "Universal Safe Character" list.

Accepted that may be true of 1.2, and true of 1.3 where it has bugs. But we should be clear to the user a) that it is a bug b) that Unicode characters and spaces should work in 1.3, but c) they may give issues if you want to give the file to someone else.

I've seen no issues with autosave, but correct me if I've missed something. Autosave only kicks in automatically if you force quit.

If I save a project with the name "this is a test/file.aup", it saves properly with that name (that is the file name as displayed in the Finder), but the window title is "this is a test:file". If I then wait for the auto-save interval, force quit Audacity then launch it, I get the recovery dialog which offers to recover the project "file - 2010-02-21 10-59-36 N-3". Note that "this is a test" is not part of the auto-save file name. The project is properly recovered, and the window title is "this is a test:file".

Recovery is OK on Windows too if I save a project with a "" in the name and force quit.

. So on Mac the project save versus export behaviours are opposite - in Save Project backslash generates an unhelpful error but forward slash works, in Export Multiple backslash works and forward slash generates an unhelpful error... going through the Mac save dialog apparently takes care of the forward-slash issue, whereas bypassing the save dialog (as in Export Multiple) generates an error.

Thanks for the summaries. It would seem where we use a standard Open/Save dialogue, by default you get operating system behaviour. So for example, if "/" is in the file name, trying to save an Audacity project on Linux will do nothing, as on most Linux apps. There would be benefits from using custom dialogues I think (especially for export, even maybe integrating export multiple and the format options explicitly into it). But it would then no longer "look" like a native Open/Save dialogue for any particular OS.



Gale

[VHF]

Thanks to everyone for the abounding insights. I was somewhat upset when I started this thread, and that probably showed, but the fact was, I had already solved the problems I myself had been having, and generated the two files I had wanted to send over the wires from raw materials I had long, long been sitting on. So, I was grateful indeed for this program that did just what I needed it to do. But the forum posting I mentioned above pointed to an essential disconnect between what was safe and legal on Audacity and what worked fine elsewhere on my Mac 10.5.8.

I was trying to empathize with new users who might not have been as resourceful and thoroughgoing as I was in finding workarounds. Apparently, it was just my use of backslash that had caused me grief, but when I was writing, I had been led to believe a whole slew of characters could cause the issues I had faced. Glad, then, to know that this is a much less universal problem than I had thought when I broached this topic.

But there is still one more issue I have with the way the elves address the problem scientifically, and that concerns the way they go about getting out of the error message Catch-22. Force quit? I doubt that most new users will try that. From their perspective there would not seem to be any apparent advantage to doing this; indeed they would likely fear that doing such might interfere with the Auto-Save function which is their seeming last hope for recovering their project. They are more likely to do what I had done: quit normally, without saving. And then, go looking for an auto-save file that has a name similar to the one they had used. In which case, they find nothing. When I next restarted Audacity, I did get a message saying that Auto-Save had something for me, but when I went to open the file, it had no signal. Big disappointment!

So, the scenario everyone seems to invoke, of force quitting and reopening Audacity might be availing, but doing so is not going to occur to most newbies.

Two things that might help: fix the text of the error message itself, as I keep saying. And, in the instructional text for the absolute beginner, encourage her to try saving the project file at the very start of her work: that way if there are any file name issues, they will evince themselves before there is a significant amount of work potentially to lose.

Well, everybody said to be specific!

[billw58]

getting out of the error message Catch-22

Not sure what you're referring to. Can't you save the project by using Save Project As and giving it a new name?

encourage her to try saving the project file at the very start of her work

Always good advice, in any program. Once the file has a slot on the disk, a simple Command-S at critical edit points keeps you safe.

-- Bill

[VHF]

Can't you save the project by using Save Project As and giving it a new name?

You forget that my Catch-22 was representing a particular perspective: that of the desperate new user who has been unduly prevented from saving her work. The error message says nothing about a problem with the file name, invokes in fact other, misleading chimera, so the newbie wouldn't have any reason to try changing the file's name as a workaround.

[waxcylinder]

You forget that my Catch-22 was representing a particular perspective: that of the desperate new user who has been unduly prevented from saving her work. The error message says nothing about a problem with the file name, invokes in fact other, misleading chimera, so the newbie wouldn't have any reason to try changing the file's name as a workaround.

VHF, I'm puzzled by this - I thought this had been fixed in 1.3.x.

Certainly I can vouch for my own experience I was exporting some WAV files only yesterday with multiple export (Audacity 1.3.9 Windows XP-HE-SP3) and I had indvertently included an illegal character in some of the songnames - a colon. Audacity refused the export of those particular songs and gave me an informative message about the illegal character.

WC

[billw58]

Certainly I can vouch for my own experience I was exporting some WAV files only yesterday with multiple export (Audacity 1.3.9 Windows XP-HE-SP3) and I had indvertently included an illegal character in some of the songnames - a colon. Audacity refused the export of those particular songs and gave me an informative message about the illegal character.

The difference is that Export Multiple does a pre-scan of label names to check for illegal characters. Save Project has no chance to do this, and just chokes with an uninformative error message. Try Save Project with a name that includes a colon or other illegal character - you'll probably get the "disk full or unwritable" error message.

-- Bill

[Gale Andrews]

Force quit? I doubt that most new users will try that. From their perspective there would not seem to be any apparent advantage to doing this; indeed they would likely fear that doing such might interfere with the Auto-Save function which is their seeming last hope for recovering their project. They are more likely to do what I had done: quit normally, without saving. And then, go looking for an auto-save file that has a name similar to the one they had used. In which case, they find nothing.

Auto-save isn't a project back-up copy. It's a way of making unsaved changes recoverable if Audacity doesn't exit normally. If it exits normally, the autosaved state is discarded:
http://manual.audacityteam.org/index.ph ... #Auto_save

When I next restarted Audacity, I did get a message saying that Auto-Save had something for me, but when I went to open the file, it had no signal. Big disappointment!

Whatever autosave that was, it must have been for an older project that did not exit normally.

fix the text of the error message itself

That isn't the answer. The error is a generic one needed when the operating system cannot write to a file for any number of reasons. What is wanted is to stop the error being thrown in that inappropriate case.



Gale

[VHF]

Yes, that's why I typed "seeming last hope." The fact was, once I hit don't save, the game was over.

Of course a developer is going to look at the larger picture, and I have said before, fixing the code so that the problem never happens in the first place is the best solution. But I don't know how high a priority this will get, especially since we are only talking now about a few errant characters. Maybe it's a big job, and maybe it's something that's easy to remedy now that the problem has been identified. Someone in my station doesn't know about such prioritization.

I do know that altering the text informing an error message must be a simple indeed thing to do, and the sooner such is in place, the sooner new users who parallel my path will be able to save their project work.

So, hopefully everything can get fixed before the release of 2.0, in which case we no longer have to worry about an "uninformative" error message! But if other matters take precedence, then some reference to the wisdom of limiting oneself to safe characters would make the message more ...informative.