true story/bug report - you DON'T want to go through what i just did!!! -ACID Product Family

Subject:true story/bug report - you DON'T want to go through what i just did!!! Posted by: Snappy Date:4/22/2003 4:52:08 PM ... which was a two-hour pants-crapping "i can't believe i just lost that song" ordeal! :( i'll spare you the suspense - everything is fully recovered* and i am breathing big sighs of relief right now. (*unless the last few volume tweaks were missed by the last autosave... no biggie - i'm more worried about the content than the mix!) but now the grueling part: I had just finished working on a song, 'tse.acd' and closed Acid (Save Changes? YES!). The working title, 'tse' had just become obsolete, so i opened my .acd folder in Windows Explorer and renamed 'tse.acd' to 'laika.acd' and 'tse.acd-bak' to 'laika.acd-bak'. Then, just to make sure the rename went off without a hitch, i double-clicked 'laika.acd', preparing to listen to it under its new title! ;) WRONG MOVE!!! Acid 4.0 immediately crashed with the WinXP "we are shutting down to prevent damage to your computer" Blue Screen Of Death! UH?! WTF?! ... the culprit was listed as w324-something-or-other.sys, which i infer is all or part of the driver for my MOTU 324. Rebooted the machine, but when i tried to load Acid, i got the message that 'there is not enough memory to run Acid. try closing programs to free more memory'. Well, trust me folks, there IS enough memory... SOOOOO now i'm starting to get a bit worried. I immediately looked in my .acd folder for 'laika'. not there! 'laika.acd-bak' NOT THERE!!!! WTF?! the only thing there was a copy of 'tse.acd' which was last modified - MARCH 15?!?!?!? NO!!!!! now it's panic time. searched my entire PC for the 'laika' files, hoping i'd misplaced them. meanwhile, tried Acid a few more times after tweaking various nodules on my system - no luck. at this point i uninstalled and reinstalled Acid. no luck. uninstalled and re-installed the MOTU software. no luck. i was almost ready to email SF tech support... and the loss of a potential masterpiece was starting to sink in... i theorized all along that _something_, probably a temp file of some sort, had gotten corrupted in the crash, and was now reporting incorrect memory information to Acid, preventing it from loading. SOOOO i searched my whole for recently-modified files, and sorted the list by 'date modified', which gave me a real nice reconstruction of what happened, even down to the last few .wav files i added to the project. WELLL here's where i got happy, cuz in the list of files i found some autosaves! woohoo! i hadn't found them before because they were in gd "c:\documents and settings\..." instead of "\my documents" where the logical individual would look. normally, this isn't a problem cuz Acid finds your temps and notifies you from within the program. BUT when Acid won't start, how are you supposed to know if there are autosaves?! in fact, FINDING the auto-saves was what enabled me to fix the problem, though, because in that same folder was a document called "Acid Pro Temp 1", which had also been modified at the time of the crash. i deleted that document, and Acid worked again (weeeeee) and notified me of my recoverable autosaves (weeeeeeeeeeeeeeee!). evidently "Acid pro temp 1" is some kind of temp folder Acid uses when it starts up, then deletes. for some reason, it didn't get deleted, and this prevented Acid from starting. (curious detail: when i got Acid working properly again, i happened to be watching the "c:\documents and settings\snappy\application data\sonic foundry\Acid\4.0\" folder when 'Acid pro temp 1' was created and deleted. when things are working properly, it appears as a normal 'folder' icon. the corrupt one i deleted, though, had the default 'unassociated file' icon, so something was obviously wrong with it) so, issue #1 (which i don't call 'a bug', although some might call it an 'error in logic' which = 'a bug'...): why is Acid putting autosave files in a folder that i don't even visit?! "c:\documents and settings\snappy\applicationdata\..." looks to me like it's supposed to be used for system files, and user documents that the user will never want to/have to look at. Well, autosave files are something i'd like to look at, so in the future, let's put them in 'my documents\my music\ACDs', ok? (I don't see this being a problem, since you're _SURE_ to add the long-overdue feature of user-definable default document path and default sound path! :P ) issue #2 (which i do call a bug :P) - if an old 'Acid Pro Temp 1' is left behind from a previous instance of running Acid, delete it so Acid can start up! and finally issue #3 (which i don't quite know what to call, except 'nasty'!): the whole "why did this thing crash in the first place???" bug... my hunch is that windows and Acid were in dispute over who had exclusive access to the 'tse' files. the renaming process may have still been 'in processing' as far as Windows was concerned, and therefore didn't let Acid have proper access to the file, and then the nasty happened! (i did double-click the file almost immediately after renaming it) i realize these interoperability bugs are some of the hardest to find, and i wouldn't be surprised if it's never heard of again, but i'm just mentioning it to the only people in the world who might possibly: A) care, and B) have a chance to do something to fix it. FINALLY, yes, i realize that to save a document, rename it, then crash the PC and come back and find the originally-named, unmodified file is pretty freaking unusual!!!! i swear this is what happened, though. since i positively renamed the correct files, the only way there could have still been a 'tse' in the folder AFTER the rename is if somehow there were TWO of them in there to begin with. This, as we all know, is impossible according to file system rules. (there aren't even any names that are close!) If, on the other hand, somehow the renaming was still 'in processing', the mysterious 'tse' files should STILL have shown their modified date as today's date and not 3/15/03, if in fact they were ever saved when i closed Acid in the first place! WHICH>>>>>>>>>>>>>>>>>>>>>>>>> leads me to a third wacked-out theory on what happened: perhaps, when i closed Acid the _first_ time and thought i saved the changes, the 'save' itself was still 'in process' at the time i started to rename the files!?! this might explain why the files never got saved properly - all new versions disappeared, and old versions were left untouched! OK that's it for now. MY APPLAUSE IF YOU'VE COME THIS FAR! =) in all seriousness: maybe this will be of help to someone(s) among u. good luck & i will post back when i have a finished version of "the song that almost wasn't" for u to listen to! =) =Snappy= cc: SF tech support edit: a message that long, u think i didn't have typos?! =P
Subject:RE: true story/bug report - you DON'T want to go through what i just did!!! Reply by: dorkus Date:4/22/2003 6:17:00 PM Nice story. I've had similar stuff happen to me countless times. I have a question: How do you "search your whole" for recently-modified files (and I'm not trying to be funny, I really want to know). Thanks, Jim
Subject:RE: true story/bug report - you DON'T want to go through what i just did!!! Reply by: Snappy Date:4/23/2003 2:17:22 PM well, first of all, you need both hands and a flashlight! for those who miss the joke and really want to know how to do this: In this case, i used Windows built in 'search' function. You should be able to find it on the Windows 'start menu' or by pressing 'F3' when you have Windows Explorer open, or are on the desktop. Once open, it should have an option to 'search for files modified between specified dates:' (that's not the actual text, but something to that effect).... sooooo to find all recently modified files on your PC, just set your search path to "my computer" and set your 'start date' and 'end date' to today's date. (or whatever's appropriate for you) as for losing stuff - yeah i've lost plenty :( most of it is in the nether now, and never got a second chance... :( when that happens, i usually won't post here, preferring to go stick my head in a hole and wait to die! :P (there is one recent project of which the only thing remaining is a screenshot of the crash screen! i will use it as a visual aid to re-create the track one day when i am really bored!) (i have to observe at this point: at least in this modern era, when i "lose" a song it's really lost! in the old days, i would "lose" songs just cuz i couldn't keep 8 different pieces of removable magnetic media together!!!!!!!!) also, when some songs get lost, u can say to yourself 'well that was nothing special, and probably just wasn't meant to be'... but this song from yesterday was really starting to go somewhere. somewhere NEW, even! it would have been a tragedy... - wouldn't it be kewl if u could take a screen shot of acid, photoshop it, then put it back in acid and play it?! =) (for that matter, wouldn't it be kewl if 'acid' became an action verb!) p.s. i'm going to re-edit the original message now, so the joke is about to become not as funny! dorkus! =P

... which was a two-hour pants-crapping "i can't believe i just lost that song" ordeal! :(

i'll spare you the suspense - everything is fully recovered* and i am breathing big sighs of relief right now. (*unless the last few volume tweaks were missed by the last autosave... no biggie - i'm more worried about the content than the mix!)

but now the grueling part:

I had just finished working on a song, 'tse.acd' and closed Acid (Save Changes? YES!). The working title, 'tse' had just become obsolete, so i opened my .acd folder in Windows Explorer and renamed 'tse.acd' to 'laika.acd' and 'tse.acd-bak' to 'laika.acd-bak'. Then, just to make sure the rename went off without a hitch, i double-clicked 'laika.acd', preparing to listen to it under its new title! ;) WRONG MOVE!!! Acid 4.0 immediately crashed with the WinXP "we are shutting down to prevent damage to your computer" Blue Screen Of Death! UH?! WTF?! ... the culprit was listed as w324-something-or-other.sys, which i infer is all or part of the driver for my MOTU 324.

Rebooted the machine, but when i tried to load Acid, i got the message that 'there is not enough memory to run Acid. try closing programs to free more memory'. Well, trust me folks, there IS enough memory... SOOOOO now i'm starting to get a bit worried. I immediately looked in my .acd folder for 'laika'. not there! 'laika.acd-bak' NOT THERE!!!! WTF?! the only thing there was a copy of 'tse.acd' which was last modified - MARCH 15?!?!?!? NO!!!!! now it's panic time. searched my entire PC for the 'laika' files, hoping i'd misplaced them. meanwhile, tried Acid a few more times after tweaking various nodules on my system - no luck.

at this point i uninstalled and reinstalled Acid. no luck. uninstalled and re-installed the MOTU software. no luck. i was almost ready to email SF tech support... and the loss of a potential masterpiece was starting to sink in...

i theorized all along that _something_, probably a temp file of some sort, had gotten corrupted in the crash, and was now reporting incorrect memory information to Acid, preventing it from loading. SOOOO i searched my whole for recently-modified files, and sorted the list by 'date modified', which gave me a real nice reconstruction of what happened, even down to the last few .wav files i added to the project.

WELLL here's where i got happy, cuz in the list of files i found some autosaves! woohoo! i hadn't found them before because they were in gd "c:\documents and settings\..." instead of "\my documents" where the logical individual would look. normally, this isn't a problem cuz Acid finds your temps and notifies you from within the program. BUT when Acid won't start, how are you supposed to know if there are autosaves?!

in fact, FINDING the auto-saves was what enabled me to fix the problem, though, because in that same folder was a document called "Acid Pro Temp 1", which had also been modified at the time of the crash. i deleted that document, and Acid worked again (weeeeee) and notified me of my recoverable autosaves (weeeeeeeeeeeeeeee!). evidently "Acid pro temp 1" is some kind of temp folder Acid uses when it starts up, then deletes. for some reason, it didn't get deleted, and this prevented Acid from starting. (curious detail: when i got Acid working properly again, i happened to be watching the "c:\documents and settings\snappy\application data\sonic foundry\Acid\4.0\" folder when 'Acid pro temp 1' was created and deleted. when things are working properly, it appears as a normal 'folder' icon. the corrupt one i deleted, though, had the default 'unassociated file' icon, so something was obviously wrong with it)

so, issue #1 (which i don't call 'a bug', although some might call it an 'error in logic' which = 'a bug'...): why is Acid putting autosave files in a folder that i don't even visit?! "c:\documents and settings\snappy\applicationdata\..." looks to me like it's supposed to be used for system files, and user documents that the user will never want to/have to look at. Well, autosave files are something i'd like to look at, so in the future, let's put them in 'my documents\my music\ACDs', ok? (I don't see this being a problem, since you're _SURE_ to add the long-overdue feature of user-definable default document path and default sound path! :P )

issue #2 (which i do call a bug :P) - if an old 'Acid Pro Temp 1' is left behind from a previous instance of running Acid, delete it so Acid can start up!

and finally issue #3 (which i don't quite know what to call, except 'nasty'!): the whole "why did this thing crash in the first place???" bug... my hunch is that windows and Acid were in dispute over who had exclusive access to the 'tse' files. the renaming process may have still been 'in processing' as far as Windows was concerned, and therefore didn't let Acid have proper access to the file, and then the nasty happened! (i did double-click the file almost immediately after renaming it) i realize these interoperability bugs are some of the hardest to find, and i wouldn't be surprised if it's never heard of again, but i'm just mentioning it to the only people in the world who might possibly: A) care, and B) have a chance to do something to fix it.

FINALLY, yes, i realize that to save a document, rename it, then crash the PC and come back and find the originally-named, unmodified file is pretty freaking unusual!!!! i swear this is what happened, though. since i positively renamed the correct files, the only way there could have still been a 'tse' in the folder AFTER the rename is if somehow there were TWO of them in there to begin with. This, as we all know, is impossible according to file system rules. (there aren't even any names that are close!) If, on the other hand, somehow the renaming was still 'in processing', the mysterious 'tse' files should STILL have shown their modified date as today's date and not 3/15/03, if in fact they were ever saved when i closed Acid in the first place! WHICH>>>>>>>>>>>>>>>>>>>>>>>>> leads me to a third wacked-out theory on what happened:

perhaps, when i closed Acid the _first_ time and thought i saved the changes, the 'save' itself was still 'in process' at the time i started to rename the files!?! this might explain why the files never got saved properly - all new versions disappeared, and old versions were left untouched!

OK that's it for now. MY APPLAUSE IF YOU'VE COME THIS FAR! =)

in all seriousness: maybe this will be of help to someone(s) among u.

good luck & i will post back when i have a finished version of "the song that almost wasn't" for u to listen to! =)

=Snappy=

cc: SF tech support

edit: a message that long, u think i didn't have typos?! =P