[Audacity-devel] bug1567-tidy is updated

Discussion:

Paul Licameli

2017-01-23 13:16:20 UTC

I did git push -f to my origin. There are now three commits in the
branch. New branch head is:

https://github.com/Paul-Licameli/audacity/commit/4059b2ae48b57cd075d9cd226cb591b939e5fc6c

The head includes the fork-and-crash fix, but could it be that we don't
need it, and the changes for cleanup of temporary files are enough?

To test whether that is so, you can checkout one or two commits before the
head. Using caret notation, you can name those as

4059b2ae^ and 4059b2ae^^

Two commits before head, you get just the change to the folder cleanup that
I wrote yesterday.

After seeing Gale's log messages, which suggest that removal of folders
does not succeed if done too soon after removal of the contents of the
folder, I added the other commit one before head. This inserts code to
delay between removing files and removing folders. As submitted, it simply
sleeps by a number that you can tune. But if you change #if 1 to #if 0,
then instead it tests in a loop whether it can detect completion of removal
of the files, but not exceeding the time limit.

So I suggest this testing:

1. See if 4059b2ae^^ is sufficient fo fix the problem of closing without
saving
2. If not, see if 4059b2ae^ does it, with a long enough sleep that is
not unreasonable
3. If #2 succeeds, verify that it also works when changing #if 1 to #if
0, but that the delays are now variable and shorter
4. If #1, #2, or #3 is enough to fix closing without saving, determine
whether it is enough for all symptoms of bug1567.

Also check that the log file no longer routinely contains (as master does,
even on my computer) error messages related to the temporary files.

PRL

Gale Andrews

2017-01-23 14:18:36 UTC

Permalink

Thanks, Paul. Are Peter or Cliff seeing the project folders in SessionData
get left behind? If so they should test too, after I figure out what combination
best deals with bug 1567 and we get that committed (all subject to RM
approval of course).

Gale

I did git push -f to my origin. There are now three commits in the branch.
https://github.com/Paul-Licameli/audacity/commit/4059b2ae48b57cd075d9cd226cb591b939e5fc6c
The head includes the fork-and-crash fix, but could it be that we don't need
it, and the changes for cleanup of temporary files are enough?
To test whether that is so, you can checkout one or two commits before the
head. Using caret notation, you can name those as
4059b2ae^ and 4059b2ae^^
Two commits before head, you get just the change to the folder cleanup that
I wrote yesterday.
After seeing Gale's log messages, which suggest that removal of folders does
not succeed if done too soon after removal of the contents of the folder, I
added the other commit one before head. This inserts code to delay between
removing files and removing folders. As submitted, it simply sleeps by a
number that you can tune. But if you change #if 1 to #if 0, then instead it
tests in a loop whether it can detect completion of removal of the files,
but not exceeding the time limit.
See if 4059b2ae^^ is sufficient fo fix the problem of closing without saving
If not, see if 4059b2ae^ does it, with a long enough sleep that is not
unreasonable
If #2 succeeds, verify that it also works when changing #if 1 to #if 0, but
that the delays are now variable and shorter
If #1, #2, or #3 is enough to fix closing without saving, determine whether
it is enough for all symptoms of bug1567.
Also check that the log file no longer routinely contains (as master does,
even on my computer) error messages related to the temporary files.
PRL
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Peter Sampson

2017-01-23 14:38:21 UTC

Permalink

Post by Gale Andrews
Thanks, Paul. Are Peter or Cliff seeing the project folders in SessionData
get left behind? If so they should test too, after I figure out what combination
best deals with bug 1567 and we get that committed (all subject to RM
approval of course).

Can this be tested with the alpha nightlies Gale, or do we need a special
build?

Peter

Gale Andrews

2017-01-23 16:36:45 UTC

Permalink

On 23 January 2017 at 14:38, Peter Sampson

Post by Peter Sampson

Can this be tested with the alpha nightlies Gale, or do we need a special
build?

By all means you could test what I suggested to Cliff in the nightlies.

And when hopefully we commit the final solution, check that there are
no errors in the log (and no empty folders in SessionData, if you had
them using the nightlies).

Gale

Peter Sampson

2017-01-23 18:17:02 UTC

Permalink

Gale,

following the steps you gave for Cliff, testing on alpha built 23Jan
I get nothing left behind in the SessionData folderwhen I quit without
the save it all gets cleaned up nicely.

All seems fine on my Macbook Sierra 10.12.2 with this alpha.

Peter.

Cliff Scott

2017-01-23 15:19:41 UTC

Permalink

Last one I built was Jan. 16th Master and the SessionData contents are totally empty after quitting Audacity. Is there some special sequence that I need to test?

Cliff

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale Andrews

2017-01-23 16:29:46 UTC

Permalink

Post by Cliff Scott
Last one I built was Jan. 16th Master and the SessionData contents
are totally empty after quitting Audacity. Is there some special sequence
that I need to test?

Just record, File > Close, don't save. New Project, record,
File > Close, don't save. I predicted you wouldn't have the
problem, being on a fast machine.

Gale

Post by Cliff Scott

Cliff Scott

2017-01-23 20:36:59 UTC

Permalink

Post by Gale Andrews

Post by Cliff Scott
Last one I built was Jan. 16th Master and the SessionData contents
are totally empty after quitting Audacity. Is there some special sequence
that I need to test?

Just record, File > Close, don't save. New Project, record,
File > Close, don't save. I predicted you wouldn't have the
problem, being on a fast machine.

You're correct. No problem. As soon as the window closes the project files disappear.

Cliff

Post by Gale Andrews
Gale

Post by Cliff Scott

David Bailes

2017-01-24 13:48:12 UTC

Permalink

Post by Paul Licameli
I did git push -f to my origin. There are now three commits in the
https://github.com/Paul-Licameli/audacity/commit/
4059b2ae48b57cd075d9cd226cb591b939e5fc6c
The head includes the fork-and-crash fix, but could it be that we don't
need it, and the changes for cleanup of temporary files are enough?
To test whether that is so, you can checkout one or two commits before the
head. Using caret notation, you can name those as
4059b2ae^ and 4059b2ae^^
Two commits before head, you get just the change to the folder cleanup
that I wrote yesterday.
After seeing Gale's log messages, which suggest that removal of folders
does not succeed if done too soon after removal of the contents of the
folder, I added the other commit one before head. This inserts code to
delay between removing files and removing folders. As submitted, it simply
sleeps by a number that you can tune. But if you change #if 1 to #if 0,
then instead it tests in a loop whether it can detect completion of removal
of the files, but not exceeding the time limit.
1. See if 4059b2ae^^ is sufficient fo fix the problem of closing
without saving
2. If not, see if 4059b2ae^ does it, with a long enough sleep that is
not unreasonable
3. If #2 succeeds, verify that it also works when changing #if 1 to
#if 0, but that the delays are now variable and shorter
4. If #1, #2, or #3 is enough to fix closing without saving, determine
whether it is enough for all symptoms of bug1567.
Also check that the log file no longer routinely contains (as master does,
even on my computer) error messages related to the temporary files.

On Windows it's easy to monitor the file activity of a program using
sysinternal's process monitor. I had a quick look round to see if there was
something equivalent on Macs, and found this:
https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/Instrument-FileActivity.html

Those working on Macs may well be already be aware of this, but I thought
I'd mention it, just in case it was of any use in tracking down any
remaining issues on Sierra.

David.

Post by Paul Licameli
PRL
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale Andrews

2017-01-24 18:21:11 UTC

Permalink

Sigh. No effect on cleaning up folders or preventing 1567 occurring
on close without save.

It doesn't stop bug 1567 occurring on close without save, even if the close
is on the final project window.

It doesn't clean up the empty folders, either in
/Users/gale/Library/Audacity/SessionData or in the default
/Users/gale/Library/Application Support/audacity/SessionData.

I see these two lines of this type in the log for each project:

16:51:34: Error: Directory
'/Users/gale/Library/Audacity/SessionData//project694592559/e00'
couldn't be deleted (error 66: Directory not empty)
16:51:34: Error: Directory
'/Users/gale/Library/Audacity/SessionData//project694592559' couldn't
be deleted (error 66: Directory not empty)

If not, see if 4059b2ae^ does it, with a long enough sleep that is not
unreasonable

As submitted, does not clean up empty folders, same message in log.

The only change is the spinning beach ball for 5 seconds presumably while
the sleep is performed. So we know that the sleep there will have an
undesirable visual consequence and I did not bother extending the sleep.

If #2 succeeds, verify that it also works when changing #if 1 to #if 0, but
that the delays are now variable and shorter

If I change #if 1 to #if 0, Audacity closes immediately on pressing "No" to
"Save changes?" with no beach ball. Log messages are unchanged.

If #1, #2, or #3 is enough to fix closing without saving, determine whether
it is enough for all symptoms of bug1567.

If I checkout 4059b2ae without carets then as expected I can now launch
Audacity guaranteed not to have bug 1567 present, but 1567 can still
occur on close without saving.

At any of those three commits, manually deleting old project folders before
close without save still stops 1567 occurring, even if there are two or more
project windows open. But if SessionData contains any project folders
which are not in use, then 1567 can trigger on close without save.

Gale

Also check that the log file no longer routinely contains (as master does,
even on my computer) error messages related to the temporary files.
PRL

Paul Licameli

2017-01-24 21:20:55 UTC

Permalink

Post by Gale Andrews
Sigh. No effect on cleaning up folders or preventing 1567 occurring
on close without save.

Post by Paul Licameli
I did git push -f to my origin. There are now three commits in the

branch.

Post by Paul Licameli
https://github.com/Paul-Licameli/audacity/commit/

4059b2ae48b57cd075d9cd226cb591b939e5fc6c

Post by Paul Licameli
The head includes the fork-and-crash fix, but could it be that we don't

need

Post by Paul Licameli
it, and the changes for cleanup of temporary files are enough?
To test whether that is so, you can checkout one or two commits before

the

Post by Paul Licameli
head. Using caret notation, you can name those as
4059b2ae^ and 4059b2ae^^
Two commits before head, you get just the change to the folder cleanup

that

Post by Paul Licameli
I wrote yesterday.
After seeing Gale's log messages, which suggest that removal of folders

does

Post by Paul Licameli
not succeed if done too soon after removal of the contents of the

folder, I

Post by Paul Licameli
added the other commit one before head. This inserts code to delay

between

Post by Paul Licameli
removing files and removing folders. As submitted, it simply sleeps by a
number that you can tune. But if you change #if 1 to #if 0, then

instead it

Post by Paul Licameli
tests in a loop whether it can detect completion of removal of the files,
but not exceeding the time limit.
See if 4059b2ae^^ is sufficient fo fix the problem of closing without

saving
It doesn't stop bug 1567 occurring on close without save, even if the close
is on the final project window.
It doesn't clean up the empty folders, either in
/Users/gale/Library/Audacity/SessionData or in the default
/Users/gale/Library/Application Support/audacity/SessionData.

Are you really sure they (look like) empty folders in Finder? No .au files
left in them? Could there be hidden files? Does ls -a from terminal list
anything else in them?

Post by Gale Andrews
16:51:34: Error: Directory
'/Users/gale/Library/Audacity/SessionData//project694592559/e00'
couldn't be deleted (error 66: Directory not empty)
16:51:34: Error: Directory
'/Users/gale/Library/Audacity/SessionData//project694592559' couldn't
be deleted (error 66: Directory not empty)

Formerly there were more and different log messages, even on my computer.
You alone get these messages that the directory is not empty. But at this
point in the program, the call to delete the .au files has completed.

Post by Gale Andrews

Post by Paul Licameli
If not, see if 4059b2ae^ does it, with a long enough sleep that is not
unreasonable

As submitted, does not clean up empty folders, same message in log.
The only change is the spinning beach ball for 5 seconds presumably while
the sleep is performed. So we know that the sleep there will have an
undesirable visual consequence and I did not bother extending the sleep.

Post by Paul Licameli
If #2 succeeds, verify that it also works when changing #if 1 to #if 0,

but

Post by Paul Licameli
that the delays are now variable and shorter

If I change #if 1 to #if 0, Audacity closes immediately on pressing "No" to
"Save changes?" with no beach ball. Log messages are unchanged.

This suggests to me that when Audacity makes calls to delete the .au files,
and then asks the file system whether the .au files are really gone, then
the answer it gets is yes, they are really gone.

So what could explain the anomaly that the log tells us the directories are
not empty? Some extraneous files are somehow added to the folders?

PRL

Post by Gale Andrews

Post by Paul Licameli
If #1, #2, or #3 is enough to fix closing without saving, determine

whether

Post by Paul Licameli
it is enough for all symptoms of bug1567.

If I checkout 4059b2ae without carets then as expected I can now launch
Audacity guaranteed not to have bug 1567 present, but 1567 can still
occur on close without saving.
At any of those three commits, manually deleting old project folders before
close without save still stops 1567 occurring, even if there are two or more
project windows open. But if SessionData contains any project folders
which are not in use, then 1567 can trigger on close without save.
Gale

Post by Paul Licameli
Also check that the log file no longer routinely contains (as master

does,

Post by Paul Licameli
even on my computer) error messages related to the temporary files.
PRL

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Paul Licameli

2017-01-24 21:46:28 UTC