Bugzilla – Bug 839
Project files open to updates by multiple users
Last modified: 2019-05-17 05:17:52 UTC
If an Audacity project file/directory is sharable by multiple users, each of those users can update the project at the same time since Audacity doesn't protect the project from simultaneous updates.
Can this case be simulated by opening the same project in different Audacity instances on the same machine? Or does the sharing need to be set up on different machines? Performing the "simulation" on the same machine, opening the same saved project in each instance, it is certainly very confusing. You can have clean version of the projects open in each instance, with different waveforms. It looks to be easy to save and close projects that will reopen with orphan and missing files, unless bug 137 is doing it (not worked out the logic yet). And if user A could tamper with the data while user B was working on the project, that could give interesting results too. So is this an enhancement or a bug? And are we now sanctioning multiple instances of Audacity on Windows without using Portable Settings? If not, is there a bug open for that?
(In reply to comment #1) > Can this case be simulated by opening the same project in different Audacity > instances on the same machine? Or does the sharing need to be set up on > different machines? > It's easier to test on Linux or OSX, but it could still happen on Windows if you use fast user switching to log into different accounts. > Performing the "simulation" on the same machine, opening the same saved project > in each instance, it is certainly very confusing. You can have clean version of > the projects open in each instance, with different waveforms. It looks to be > easy to save and close projects that will reopen with orphan and missing files, > unless bug 137 is doing it (not worked out the logic yet). And if user A could > tamper with the data while user B was working on the project, that could give > interesting results too. > > So is this an enhancement or a bug? > Honestly it is a bug, but I put it as an enhancement since it's not really all that likely to happen...well, I wouldn't bet a paycheck on that though. > And are we now sanctioning multiple instances of Audacity on Windows without > using Portable Settings? If not, is there a bug open for that? No, is that still happening for you after r13887???
(In reply to comment #2) > > And are we now sanctioning multiple instances of Audacity on Windows without > > using Portable Settings? If not, is there a bug open for that? > No, is that still happening for you after r13887??? Seemingly only in the specific case of running HEAD then a build older than HEAD (obviously having a different name) from the same folder. For example, HEAD with a build from yesterday. Either can be run first to get two instances. If I launch HEAD then an older build from another folder (named as audacity.exe or otherwise) then the call for the older build gets passed to HEAD. I'm still to test launching HEAD then using "Open with" for some file type set to an older build of Audacity. I'm getting newly created file associations set to 2.0.6 opening in HEAD when no Audacity version is running, so it looks like I need to fix that before I can test.
Provisionally set to P4. Could be promoted to P3 if it's easy to do on OS X / Linux. The Fast User Switching setting is exposed to user on XP, but fortunately hidden away on later Windows.
(In reply to comment #3) > (In reply to comment #2) > > > And are we now sanctioning multiple instances of Audacity on Windows without > > > using Portable Settings? If not, is there a bug open for that? > > No, is that still happening for you after r13887??? > Seemingly only in the specific case of running HEAD then a build older than > HEAD (obviously having a different name) from the same folder. For example, > HEAD with a build from yesterday. Either can be run first to get two instances. > Whew...that makes since then. Any build between r13868 and r13887 will present this problem. But, to be certain, are you able to run HEAD and 2.0.6 at the same time?
(In reply to comment #4) > Provisionally set to P4. Could be promoted to P3 if it's easy to do on OS X / > Linux. The Fast User Switching setting is exposed to user on XP, but > fortunately hidden away on later Windows. Isn't the "Switch User" on the Windows 7 start menu the same thing??? I could be wrong as I never use it.
Created attachment 560 [details] The "switch user" I was talking about
(In reply to comment #6) >> The Fast User Switching setting is exposed to user on XP, but >> fortunately hidden away on later Windows. > Isn't the "Switch User" on the Windows 7 start menu the same thing??? Yes that item is the so-called Fast User Switching. The setting to make that menu item visible or not is indeed hidden in Vista and later ( http://www.addictivetips.com/windows-tips/how-to-enable-disable-fast-user-switching-in-windows-xp-and-windows-vista/ ) but it does seem that item is visible by default on most Windows versions. Perhaps because I have Windows 7 Ultimate, I had to make that item visible in Group Policy Editor. Having switched to another user in the Win 7 switcher, I have to log back in to my admin account even though I remain logged in all the time. The old Faster User Switcher PowerToy for XP bypassed the Welcome Screen you have to go through on Win 7 and was more convenient. So now it seems user switching on Win is easier than I thought, perhaps this issue could be P3 after all.
(In reply to comment #5) >>>> And are we now sanctioning multiple instances of Audacity on >>>> Windows >without >>>> using Portable Settings? If not, is there a bug open for that? >>> No, is that still happening for you after r13887??? >> Seemingly only in the specific case of running HEAD then a build older than >> HEAD (obviously having a different name) from the same folder. For example, >> HEAD with a build from yesterday. Either can be run first to get two >> instances. > Whew...that makes since then. Any build between r13868 and r13887 will present > this problem. But, to be certain, are you able to run HEAD and 2.0.6 at the > same time? Just by executing them by double-click (either one first) they can't be run together from separate folders. But I still have to test "open with", and I can't test 2.0.6 and 2.1.0-alpha in the same folder on this machine because 2.1.0 here was built with VS2013 (as I assume the release will be, of course).
*** STEPS UPDATED *** Demoted to P5 as my reading of the residual is that it requires an old version of Audacity to pull off this stunt.
Could we not just close this bug and instead add it as an oblique entry to the multi-project worm-can? It is, when all is said and done, an extremely unlikely occurrence. Maybe it is something to consider (and block) if and when we work on the unified project structure ?
