bug1567-tidy is updated

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug1567-tidy is updated

Paul Licameli
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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bug1567-tidy is updated

Gale
Administrator
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


On 23 January 2017 at 13:16, Paul Licameli <[hidden email]> wrote:

> 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:
>
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bug1567-tidy is updated

Peter Sampson-2
Gale wrote:
>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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bug1567-tidy is updated

Cliff Scott
In reply to this post by Gale
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

> On Jan 23, 2017, at 8:18 AM, Gale Andrews <[hidden email]> wrote:
>
> 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
>
>
> On 23 January 2017 at 13:16, Paul Licameli <[hidden email]> wrote:
>> 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:
>>
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bug1567-tidy is updated

Gale
Administrator
On 23 January 2017 at 15:19, Cliff Scott <[hidden email]> wrote:
> 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

>> On Jan 23, 2017, at 8:18 AM, Gale Andrews <[hidden email]> wrote:
>>
>> 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
>>
>>
>> On 23 January 2017 at 13:16, Paul Licameli <[hidden email]> wrote:
>>> 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:
>>>
>>> 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
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bug1567-tidy is updated

Gale
Administrator
In reply to this post by Peter Sampson-2
On 23 January 2017 at 14:38, Peter Sampson
<[hidden email]> wrote:
> Gale wrote:
>>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?

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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bug1567-tidy is updated

Peter Sampson-2
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.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bug1567-tidy is updated

Cliff Scott
In reply to this post by Gale

> On Jan 23, 2017, at 10:29 AM, Gale Andrews <[hidden email]> wrote:
>
> On 23 January 2017 at 15:19, Cliff Scott <[hidden email]> wrote:
>> 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

>
>
> Gale
>
>>> On Jan 23, 2017, at 8:18 AM, Gale Andrews <[hidden email]> wrote:
>>>
>>> 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
>>>
>>>
>>> On 23 January 2017 at 13:16, Paul Licameli <[hidden email]> wrote:
>>>> 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:
>>>>
>>>> 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
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bug1567-tidy is updated

David Bailes-3
In reply to this post by Paul Licameli
On Mon, Jan 23, 2017 at 1:16 PM, Paul Licameli <[hidden email]> wrote:
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.

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: 

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.


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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bug1567-tidy is updated

Gale
Administrator
In reply to this post by Paul Licameli
Sigh. No effect on cleaning up folders or preventing 1567 occurring
on close without save.

On 23 January 2017 at 13:16, Paul Licameli <[hidden email]> wrote:

> 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:
>
> 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.

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
>
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bug1567-tidy is updated

Paul Licameli


On Tue, Jan 24, 2017 at 1:21 PM, Gale Andrews <[hidden email]> wrote:
Sigh. No effect on cleaning up folders or preventing 1567 occurring
on close without save.

On 23 January 2017 at 13:16, Paul Licameli <[hidden email]> wrote:
> 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:
>
> 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?
 

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)

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.
 


> 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.

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
 


> 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
>
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bug1567-tidy is updated

Paul Licameli


On Tue, Jan 24, 2017 at 4:20 PM, Paul Licameli <[hidden email]> wrote:


On Tue, Jan 24, 2017 at 1:21 PM, Gale Andrews <[hidden email]> wrote:
Sigh. No effect on cleaning up folders or preventing 1567 occurring
on close without save.

On 23 January 2017 at 13:16, Paul Licameli <[hidden email]> wrote:
> 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:
>
> 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?
 

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)

Specifically there used to be "operation not permitted" messages in the log, but now no longer, right?  It is something, that the log is tidier, even on my machine which does not suffer bug 1567.

Is this list of log messages complete?

I now notice this:  you did NOT see a log message for the etc/e00/d00 directory.  There should have been such a directory in the tree.  So it may not be that .au files are not cleaned up (in fact they should normally be deleted already at this point), but rather that the d00 folder was not removed.

So now I don't know what is going wrong:

Audacity did not attempt to remove d00.
Or it did, but that failed silently without a log message.
Or it did, but a sleep is needed before attempting to remove the folder above it.

But this means I have not run out of experiments for you yet.

PRL

 

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.
 


> 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.

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
 


> 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
>
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bug1567-tidy is updated

Paul Licameli


On Tue, Jan 24, 2017 at 4:46 PM, Paul Licameli <[hidden email]> wrote:


On Tue, Jan 24, 2017 at 4:20 PM, Paul Licameli <[hidden email]> wrote:


On Tue, Jan 24, 2017 at 1:21 PM, Gale Andrews <[hidden email]> wrote:
Sigh. No effect on cleaning up folders or preventing 1567 occurring
on close without save.

On 23 January 2017 at 13:16, Paul Licameli <[hidden email]> wrote:
> 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:
>
> 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?
 

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)

Specifically there used to be "operation not permitted" messages in the log, but now no longer, right?  It is something, that the log is tidier, even on my machine which does not suffer bug 1567.

Is this list of log messages complete?

I now notice this:  you did NOT see a log message for the etc/e00/d00 directory.  There should have been such a directory in the tree.  So it may not be that .au files are not cleaned up (in fact they should normally be deleted already at this point), but rather that the d00 folder was not removed.

So now I don't know what is going wrong:

Audacity did not attempt to remove d00.
Or it did, but that failed silently without a log message.
Or it did, but a sleep is needed before attempting to remove the folder above it.

But this means I have not run out of experiments for you yet.

PRL

So here is what you can do while I write something else:  Verify that folder .../e00/d00 exists before you close without saving.  Do the close without saving in HEAD, with its failed, incomplete cleanup.  Is e00 still present but e00/d00 removed?

If that is so, then this would suggest to me that Audacity did in fact successfully find and remove the lowest-level folder, but the removal of it is somehow asynchronously completed on Sierra, and Audacity should pause a bit after removing each folder, before trying to remove its parent.  There may be many folders, so this must be a small pause at most, but maybe only a few milliseconds after each is what we need.

PRL

 

 

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.
 


> 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.

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
 


> 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
>
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel




------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bug1567-tidy is updated

Paul Licameli
Updated again:

https://github.com/Paul-Licameli/audacity/commit/0988c427b9efd31f26491712f01cc15b46dac085

Now there are four commits.  The first should not fix the bugs but will be desirable to avoid log messages about "operation not permitted."  The second does the insufficient, probably unnecessary, but harmless loop to verify that .au files are removed, waiting at most one second.

What is interesting now is the third commit, which you can call 0988c427^ .  Again, it adds a sleep that you can tune, but only 100 ms as written, after removal of each folder.  Again, you can change #if 0 to #if 1 so that this number is an upper bound on the wait, which may be shorter.  Again, I want to know if this turns out to be sufficient to fix bug 1567, without the branch tip commit, 0988c427.

PRL


On Tue, Jan 24, 2017 at 4:57 PM, Paul Licameli <[hidden email]> wrote:


On Tue, Jan 24, 2017 at 4:46 PM, Paul Licameli <[hidden email]> wrote:


On Tue, Jan 24, 2017 at 4:20 PM, Paul Licameli <[hidden email]> wrote:


On Tue, Jan 24, 2017 at 1:21 PM, Gale Andrews <[hidden email]> wrote:
Sigh. No effect on cleaning up folders or preventing 1567 occurring
on close without save.

On 23 January 2017 at 13:16, Paul Licameli <[hidden email]> wrote:
> 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:
>
> 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?
 

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)

Specifically there used to be "operation not permitted" messages in the log, but now no longer, right?  It is something, that the log is tidier, even on my machine which does not suffer bug 1567.

Is this list of log messages complete?

I now notice this:  you did NOT see a log message for the etc/e00/d00 directory.  There should have been such a directory in the tree.  So it may not be that .au files are not cleaned up (in fact they should normally be deleted already at this point), but rather that the d00 folder was not removed.

So now I don't know what is going wrong:

Audacity did not attempt to remove d00.
Or it did, but that failed silently without a log message.
Or it did, but a sleep is needed before attempting to remove the folder above it.

But this means I have not run out of experiments for you yet.

PRL

So here is what you can do while I write something else:  Verify that folder .../e00/d00 exists before you close without saving.  Do the close without saving in HEAD, with its failed, incomplete cleanup.  Is e00 still present but e00/d00 removed?

If that is so, then this would suggest to me that Audacity did in fact successfully find and remove the lowest-level folder, but the removal of it is somehow asynchronously completed on Sierra, and Audacity should pause a bit after removing each folder, before trying to remove its parent.  There may be many folders, so this must be a small pause at most, but maybe only a few milliseconds after each is what we need.

PRL

 

 

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.
 


> 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.

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
 


> 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
>
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel





------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bug1567-tidy is updated

Gale
Administrator
In reply to this post by Paul Licameli
Paul, right now I'm just going to answer your questions as background
info, inline in each message.


On 24 January 2017 at 21:20, Paul Licameli <[hidden email]> wrote:

>
>
> On Tue, Jan 24, 2017 at 1:21 PM, Gale Andrews <[hidden email]> wrote:
>>
>> Sigh. No effect on cleaning up folders or preventing 1567 occurring
>> on close without save.
>>
>> On 23 January 2017 at 13:16, Paul Licameli <[hidden email]>
>> wrote:
>> > 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:
>> >
>> > 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?

Yes, in Finder, the project folder "looks" empty except for an "e00" folder.

The e00 folder looks empty. The "d00" folder and its files have been
deleted, per their absence from the log message cited a few lines
below.

>  Could there be hidden files?  Does ls -a from terminal list anything
> else in them?

ls -a shows a .DS_Store file in the root of the project folder, and e00
as completely empty.


Gale

>> 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)
>
>
> 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.
>
>>
>>
>>
>> > 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.
>
>
> 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
>
>>
>>
>>
>> > 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
>> >
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bug1567-tidy is updated

Gale
Administrator
In reply to this post by Paul Licameli
On 24 January 2017 at 21:46, Paul Licameli <[hidden email]> wrote:

>
>
> On Tue, Jan 24, 2017 at 4:20 PM, Paul Licameli <[hidden email]>
> wrote:
>>
>>
>>
>> On Tue, Jan 24, 2017 at 1:21 PM, Gale Andrews <[hidden email]>
>> wrote:
>>>
>>> Sigh. No effect on cleaning up folders or preventing 1567 occurring
>>> on close without save.
>>>
>>> On 23 January 2017 at 13:16, Paul Licameli <[hidden email]>
>>> wrote:
>>> > 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:
>>> >
>>> > 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?
>>
>>>
>>>
>>> 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)
>
>
> Specifically there used to be "operation not permitted" messages in the log,
> but now no longer, right?

Yes, "Operation not permitted" was there before, just for the erroneous
deletion of a folder as a file.

> It is something, that the log is tidier, even on my machine which does not
> suffer bug 1567.
>
> Is this list of log messages complete?

Yes, each project just has those two lines with the corresponding
change for the project number.


> I now notice this:  you did NOT see a log message for the etc/e00/d00
> directory.  There should have been such a directory in the tree.  So it may
> not be that .au files are not cleaned up (in fact they should normally be
> deleted already at this point), but rather that the d00 folder was not
> removed.
>
> So now I don't know what is going wrong:
>
> Audacity did not attempt to remove d00.
> Or it did, but that failed silently without a log message.
> Or it did, but a sleep is needed before attempting to remove the folder
> above it.

As previous message, it did delete the d00 folder, but not e00 above it.


Gale

> But this means I have not run out of experiments for you yet.
>
> PRL
>
>
>>
>>
>> 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.
>>
>>>
>>>
>>>
>>> > 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.
>>
>>
>> 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
>>
>>>
>>>
>>>
>>> > 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
>>> >
>>> >
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bug1567-tidy is updated

Gale
Administrator
In reply to this post by Paul Licameli
On 24 January 2017 at 21:57, Paul Licameli <[hidden email]> wrote:

>
>
> On Tue, Jan 24, 2017 at 4:46 PM, Paul Licameli <[hidden email]>
> wrote:
>>
>>
>>
>> On Tue, Jan 24, 2017 at 4:20 PM, Paul Licameli <[hidden email]>
>> wrote:
>>>
>>>
>>>
>>> On Tue, Jan 24, 2017 at 1:21 PM, Gale Andrews <[hidden email]>
>>> wrote:
>>>>
>>>> Sigh. No effect on cleaning up folders or preventing 1567 occurring
>>>> on close without save.
>>>>
>>>> On 23 January 2017 at 13:16, Paul Licameli <[hidden email]>
>>>> wrote:
>>>> > 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:
>>>> >
>>>> > 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?
>>>
>>>>
>>>>
>>>> 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)
>>
>>
>> Specifically there used to be "operation not permitted" messages in the
>> log, but now no longer, right?  It is something, that the log is tidier,
>> even on my machine which does not suffer bug 1567.
>>
>> Is this list of log messages complete?
>>
>> I now notice this:  you did NOT see a log message for the etc/e00/d00
>> directory.  There should have been such a directory in the tree.  So it may
>> not be that .au files are not cleaned up (in fact they should normally be
>> deleted already at this point), but rather that the d00 folder was not
>> removed.
>>
>> So now I don't know what is going wrong:
>>
>> Audacity did not attempt to remove d00.
>> Or it did, but that failed silently without a log message.
>> Or it did, but a sleep is needed before attempting to remove the folder
>> above it.
>>
>> But this means I have not run out of experiments for you yet.
>>
>> PRL
>
>
> So here is what you can do while I write something else:  Verify that folder
> .../e00/d00 exists before you close without saving.  Do the close without
> saving in HEAD, with its failed, incomplete cleanup.  Is e00 still present
> but e00/d00 removed?

Yes, HEAD still behaves as reported in bug 1521 - d00 is removed leaving
an empty e00.


Gale


> If that is so, then this would suggest to me that Audacity did in fact
> successfully find and remove the lowest-level folder, but the removal of it
> is somehow asynchronously completed on Sierra, and Audacity should pause a
> bit after removing each folder, before trying to remove its parent.  There
> may be many folders, so this must be a small pause at most, but maybe only a
> few milliseconds after each is what we need.
>
> PRL
>
>
>>
>>
>>
>>>
>>>
>>> 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.
>>>
>>>>
>>>>
>>>>
>>>> > 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.
>>>
>>>
>>> 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
>>>
>>>>
>>>>
>>>>
>>>> > 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
>>>> >
>>>> >
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bug1567-tidy is updated

Gale
Administrator
In reply to this post by Paul Licameli
On 24 January 2017 at 23:01, Paul Licameli <[hidden email]> wrote:

> Updated again:
>
> https://github.com/Paul-Licameli/audacity/commit/0988c427b9efd31f26491712f01cc15b46dac085
>
> Now there are four commits.  The first should not fix the bugs but will be
> desirable to avoid log messages about "operation not permitted."  The second
> does the insufficient, probably unnecessary, but harmless loop to verify
> that .au files are removed, waiting at most one second.
>
> What is interesting now is the third commit, which you can call 0988c427^ .
> Again, it adds a sleep that you can tune, but only 100 ms as written, after
> removal of each folder.

The only new behaviour with this commit is the progress dialogue for
cleaning up temporary files. This takes 75 seconds to complete. SessionData
contains six old projects, each with an empty e00 folder, plus the one
project which is the project just closed.

All the project*/e00 folders remain after this cleanup attempt.

Log (I added the line breaks for readability):

01:57:55: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1186281344/e00' couldn't be
deleted (error 66: Directory not empty)
01:58:00: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1186281344' couldn't be deleted
(error 66: Directory not empty)

01:58:05: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1188197342/e00' couldn't be
deleted (error 66: Directory not empty)
01:58:10: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1188197342' couldn't be deleted
(error 66: Directory not empty)

01:58:15: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1189827621/e00' couldn't be
deleted (error 66: Directory not empty)
01:58:20: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1189827621' couldn't be deleted
(error 66: Directory not empty)

01:58:25: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1192953723/e00' couldn't be
deleted (error 66: Directory not empty)
01:58:30: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1192953723' couldn't be deleted
(error 66: Directory not empty)

01:58:35: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1193777266/e00' couldn't be
deleted (error 66: Directory not empty)
01:58:40: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1193777266' couldn't be deleted
(error 66: Directory not empty)

01:58:45: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1229206422/e00' couldn't be
deleted (error 66: Directory not empty)
01:58:50: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1229206422' couldn't be deleted
(error 66: Directory not empty)

01:59:00: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1245307528/e00' couldn't be
deleted (error 66: Directory not empty)
01:59:05: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1245307528' couldn't be deleted
(error 66: Directory not empty)

>  gain, you can change #if 0 to #if 1 so that this  number is an upper bound
> on the wait, which may be shorter.

This just adds the spinning beach ball lasting as long as the specified wait,
before the progress dialogue appears. I tried 5000 ms with no difference.


> Again, I want to know if this turns out to be sufficient to fix bug 1567, without the
> branch tip commit, 0988c427.

No - it does not.

I tried deleting these same e00 and project* folders, one at a time in FileZilla
3.24.0, which uses wxWidgets 3.0.3. This deletion went without problem and
was instantaneous.

Manually deleting the .DS_Store files in the project* folders before asking
Audacity to delete the folders does not change anything.


Gale

> On Tue, Jan 24, 2017 at 4:57 PM, Paul Licameli <[hidden email]>
> wrote:
>>
>>
>>
>> On Tue, Jan 24, 2017 at 4:46 PM, Paul Licameli <[hidden email]>
>> wrote:
>>>
>>>
>>>
>>> On Tue, Jan 24, 2017 at 4:20 PM, Paul Licameli <[hidden email]>
>>> wrote:
>>>>
>>>>
>>>>
>>>> On Tue, Jan 24, 2017 at 1:21 PM, Gale Andrews <[hidden email]>
>>>> wrote:
>>>>>
>>>>> Sigh. No effect on cleaning up folders or preventing 1567 occurring
>>>>> on close without save.
>>>>>
>>>>> On 23 January 2017 at 13:16, Paul Licameli <[hidden email]>
>>>>> wrote:
>>>>> > 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:
>>>>> >
>>>>> > 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?
>>>>
>>>>>
>>>>>
>>>>> 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)
>>>
>>>
>>> Specifically there used to be "operation not permitted" messages in the
>>> log, but now no longer, right?  It is something, that the log is tidier,
>>> even on my machine which does not suffer bug 1567.
>>>
>>> Is this list of log messages complete?
>>>
>>> I now notice this:  you did NOT see a log message for the etc/e00/d00
>>> directory.  There should have been such a directory in the tree.  So it may
>>> not be that .au files are not cleaned up (in fact they should normally be
>>> deleted already at this point), but rather that the d00 folder was not
>>> removed.
>>>
>>> So now I don't know what is going wrong:
>>>
>>> Audacity did not attempt to remove d00.
>>> Or it did, but that failed silently without a log message.
>>> Or it did, but a sleep is needed before attempting to remove the folder
>>> above it.
>>>
>>> But this means I have not run out of experiments for you yet.
>>>
>>> PRL
>>
>>
>> So here is what you can do while I write something else:  Verify that
>> folder .../e00/d00 exists before you close without saving.  Do the close
>> without saving in HEAD, with its failed, incomplete cleanup.  Is e00 still
>> present but e00/d00 removed?
>>
>> If that is so, then this would suggest to me that Audacity did in fact
>> successfully find and remove the lowest-level folder, but the removal of it
>> is somehow asynchronously completed on Sierra, and Audacity should pause a
>> bit after removing each folder, before trying to remove its parent.  There
>> may be many folders, so this must be a small pause at most, but maybe only a
>> few milliseconds after each is what we need.
>>
>> PRL
>>
>>
>>>
>>>
>>>
>>>>
>>>>
>>>> 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.
>>>>
>>>>>
>>>>>
>>>>>
>>>>> > 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.
>>>>
>>>>
>>>> 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
>>>>
>>>>>
>>>>>
>>>>>
>>>>> > 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
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> 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
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>
>>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bug1567-tidy is updated

Paul Licameli


On Tue, Jan 24, 2017 at 9:39 PM, Gale Andrews <[hidden email]> wrote:
On 24 January 2017 at 23:01, Paul Licameli <[hidden email]> wrote:
> Updated again:
>
> https://github.com/Paul-Licameli/audacity/commit/0988c427b9efd31f26491712f01cc15b46dac085
>
> Now there are four commits.  The first should not fix the bugs but will be
> desirable to avoid log messages about "operation not permitted."  The second
> does the insufficient, probably unnecessary, but harmless loop to verify
> that .au files are removed, waiting at most one second.
>
> What is interesting now is the third commit, which you can call 0988c427^ .
> Again, it adds a sleep that you can tune, but only 100 ms as written, after
> removal of each folder.

The only new behaviour with this commit is the progress dialogue for
cleaning up temporary files. This takes 75 seconds to complete. SessionData
contains six old projects, each with an empty e00 folder, plus the one
project which is the project just closed.

All the project*/e00 folders remain after this cleanup attempt.

Log (I added the line breaks for readability):

01:57:55: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1186281344/e00' couldn't be
deleted (error 66: Directory not empty)
01:58:00: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1186281344' couldn't be deleted
(error 66: Directory not empty)

01:58:05: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1188197342/e00' couldn't be
deleted (error 66: Directory not empty)
01:58:10: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1188197342' couldn't be deleted
(error 66: Directory not empty)

01:58:15: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1189827621/e00' couldn't be
deleted (error 66: Directory not empty)
01:58:20: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1189827621' couldn't be deleted
(error 66: Directory not empty)

01:58:25: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1192953723/e00' couldn't be
deleted (error 66: Directory not empty)
01:58:30: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1192953723' couldn't be deleted
(error 66: Directory not empty)

01:58:35: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1193777266/e00' couldn't be
deleted (error 66: Directory not empty)
01:58:40: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1193777266' couldn't be deleted
(error 66: Directory not empty)

01:58:45: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1229206422/e00' couldn't be
deleted (error 66: Directory not empty)
01:58:50: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1229206422' couldn't be deleted
(error 66: Directory not empty)

01:59:00: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1245307528/e00' couldn't be
deleted (error 66: Directory not empty)
01:59:05: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1245307528' couldn't be deleted
(error 66: Directory not empty)

>  gain, you can change #if 0 to #if 1 so that this  number is an upper bound
> on the wait, which may be shorter.

This just adds the spinning beach ball lasting as long as the specified wait,
before the progress dialogue appears. I tried 5000 ms with no difference.


> Again, I want to know if this turns out to be sufficient to fix bug 1567, without the
> branch tip commit, 0988c427.

No - it does not.

I tried deleting these same e00 and project* folders, one at a time in FileZilla
3.24.0, which uses wxWidgets 3.0.3. This deletion went without problem and
was instantaneous.

Manually deleting the .DS_Store files in the project* folders before asking
Audacity to delete the folders does not change anything.


Well, this makes no sense.  It appears the Audacity program is told that the folder is not empty, when other programs tell us that it is.

The only other thing I can think of, is that you use terminal, and type
ls -a .../e00

with whatever substitution for ... and this might tell us about certain hidden files that Finder might not be showing.

PRL

 

Gale

> On Tue, Jan 24, 2017 at 4:57 PM, Paul Licameli <[hidden email]>
> wrote:
>>
>>
>>
>> On Tue, Jan 24, 2017 at 4:46 PM, Paul Licameli <[hidden email]>
>> wrote:
>>>
>>>
>>>
>>> On Tue, Jan 24, 2017 at 4:20 PM, Paul Licameli <[hidden email]>
>>> wrote:
>>>>
>>>>
>>>>
>>>> On Tue, Jan 24, 2017 at 1:21 PM, Gale Andrews <[hidden email]>
>>>> wrote:
>>>>>
>>>>> Sigh. No effect on cleaning up folders or preventing 1567 occurring
>>>>> on close without save.
>>>>>
>>>>> On 23 January 2017 at 13:16, Paul Licameli <[hidden email]>
>>>>> wrote:
>>>>> > 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:
>>>>> >
>>>>> > 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?
>>>>
>>>>>
>>>>>
>>>>> 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)
>>>
>>>
>>> Specifically there used to be "operation not permitted" messages in the
>>> log, but now no longer, right?  It is something, that the log is tidier,
>>> even on my machine which does not suffer bug 1567.
>>>
>>> Is this list of log messages complete?
>>>
>>> I now notice this:  you did NOT see a log message for the etc/e00/d00
>>> directory.  There should have been such a directory in the tree.  So it may
>>> not be that .au files are not cleaned up (in fact they should normally be
>>> deleted already at this point), but rather that the d00 folder was not
>>> removed.
>>>
>>> So now I don't know what is going wrong:
>>>
>>> Audacity did not attempt to remove d00.
>>> Or it did, but that failed silently without a log message.
>>> Or it did, but a sleep is needed before attempting to remove the folder
>>> above it.
>>>
>>> But this means I have not run out of experiments for you yet.
>>>
>>> PRL
>>
>>
>> So here is what you can do while I write something else:  Verify that
>> folder .../e00/d00 exists before you close without saving.  Do the close
>> without saving in HEAD, with its failed, incomplete cleanup.  Is e00 still
>> present but e00/d00 removed?
>>
>> If that is so, then this would suggest to me that Audacity did in fact
>> successfully find and remove the lowest-level folder, but the removal of it
>> is somehow asynchronously completed on Sierra, and Audacity should pause a
>> bit after removing each folder, before trying to remove its parent.  There
>> may be many folders, so this must be a small pause at most, but maybe only a
>> few milliseconds after each is what we need.
>>
>> PRL
>>
>>
>>>
>>>
>>>
>>>>
>>>>
>>>> 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.
>>>>
>>>>>
>>>>>
>>>>>
>>>>> > 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.
>>>>
>>>>
>>>> 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
>>>>
>>>>>
>>>>>
>>>>>
>>>>> > 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
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> 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
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>
>>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bug1567-tidy is updated

Paul Licameli
I pushed another commit, a1b6aadf, which should write something to the log when there is a failure to remove one of these folders.  Though after closing the last window, you must open a new window, in order to have the Help menu available so you can see the log again.

There should either be messages that the folder that did not delete can't be enumerated, or else, a list of the files that wxWidgets still detects inside it.

(I'm feeling very frustrated with this, Gale.  You?)

PRL


On Tue, Jan 24, 2017 at 10:20 PM, Paul Licameli <[hidden email]> wrote:


On Tue, Jan 24, 2017 at 9:39 PM, Gale Andrews <[hidden email]> wrote:
On 24 January 2017 at 23:01, Paul Licameli <[hidden email]> wrote:
> Updated again:
>
> https://github.com/Paul-Licameli/audacity/commit/0988c427b9efd31f26491712f01cc15b46dac085
>
> Now there are four commits.  The first should not fix the bugs but will be
> desirable to avoid log messages about "operation not permitted."  The second
> does the insufficient, probably unnecessary, but harmless loop to verify
> that .au files are removed, waiting at most one second.
>
> What is interesting now is the third commit, which you can call 0988c427^ .
> Again, it adds a sleep that you can tune, but only 100 ms as written, after
> removal of each folder.

The only new behaviour with this commit is the progress dialogue for
cleaning up temporary files. This takes 75 seconds to complete. SessionData
contains six old projects, each with an empty e00 folder, plus the one
project which is the project just closed.

All the project*/e00 folders remain after this cleanup attempt.

Log (I added the line breaks for readability):

01:57:55: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1186281344/e00' couldn't be
deleted (error 66: Directory not empty)
01:58:00: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1186281344' couldn't be deleted
(error 66: Directory not empty)

01:58:05: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1188197342/e00' couldn't be
deleted (error 66: Directory not empty)
01:58:10: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1188197342' couldn't be deleted
(error 66: Directory not empty)

01:58:15: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1189827621/e00' couldn't be
deleted (error 66: Directory not empty)
01:58:20: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1189827621' couldn't be deleted
(error 66: Directory not empty)

01:58:25: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1192953723/e00' couldn't be
deleted (error 66: Directory not empty)
01:58:30: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1192953723' couldn't be deleted
(error 66: Directory not empty)

01:58:35: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1193777266/e00' couldn't be
deleted (error 66: Directory not empty)
01:58:40: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1193777266' couldn't be deleted
(error 66: Directory not empty)

01:58:45: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1229206422/e00' couldn't be
deleted (error 66: Directory not empty)
01:58:50: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1229206422' couldn't be deleted
(error 66: Directory not empty)

01:59:00: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1245307528/e00' couldn't be
deleted (error 66: Directory not empty)
01:59:05: Error: Directory '/Users/gale/Library/Application
Support/audacity/SessionData/project1245307528' couldn't be deleted
(error 66: Directory not empty)

>  gain, you can change #if 0 to #if 1 so that this  number is an upper bound
> on the wait, which may be shorter.

This just adds the spinning beach ball lasting as long as the specified wait,
before the progress dialogue appears. I tried 5000 ms with no difference.


> Again, I want to know if this turns out to be sufficient to fix bug 1567, without the
> branch tip commit, 0988c427.

No - it does not.

I tried deleting these same e00 and project* folders, one at a time in FileZilla
3.24.0, which uses wxWidgets 3.0.3. This deletion went without problem and
was instantaneous.

Manually deleting the .DS_Store files in the project* folders before asking
Audacity to delete the folders does not change anything.


Well, this makes no sense.  It appears the Audacity program is told that the folder is not empty, when other programs tell us that it is.

The only other thing I can think of, is that you use terminal, and type
ls -a .../e00

with whatever substitution for ... and this might tell us about certain hidden files that Finder might not be showing.

PRL

 

Gale

> On Tue, Jan 24, 2017 at 4:57 PM, Paul Licameli <[hidden email]>
> wrote:
>>
>>
>>
>> On Tue, Jan 24, 2017 at 4:46 PM, Paul Licameli <[hidden email]>
>> wrote:
>>>
>>>
>>>
>>> On Tue, Jan 24, 2017 at 4:20 PM, Paul Licameli <[hidden email]>
>>> wrote:
>>>>
>>>>
>>>>
>>>> On Tue, Jan 24, 2017 at 1:21 PM, Gale Andrews <[hidden email]>
>>>> wrote:
>>>>>
>>>>> Sigh. No effect on cleaning up folders or preventing 1567 occurring
>>>>> on close without save.
>>>>>
>>>>> On 23 January 2017 at 13:16, Paul Licameli <[hidden email]>
>>>>> wrote:
>>>>> > 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:
>>>>> >
>>>>> > 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?
>>>>
>>>>>
>>>>>
>>>>> 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)
>>>
>>>
>>> Specifically there used to be "operation not permitted" messages in the
>>> log, but now no longer, right?  It is something, that the log is tidier,
>>> even on my machine which does not suffer bug 1567.
>>>
>>> Is this list of log messages complete?
>>>
>>> I now notice this:  you did NOT see a log message for the etc/e00/d00
>>> directory.  There should have been such a directory in the tree.  So it may
>>> not be that .au files are not cleaned up (in fact they should normally be
>>> deleted already at this point), but rather that the d00 folder was not
>>> removed.
>>>
>>> So now I don't know what is going wrong:
>>>
>>> Audacity did not attempt to remove d00.
>>> Or it did, but that failed silently without a log message.
>>> Or it did, but a sleep is needed before attempting to remove the folder
>>> above it.
>>>
>>> But this means I have not run out of experiments for you yet.
>>>
>>> PRL
>>
>>
>> So here is what you can do while I write something else:  Verify that
>> folder .../e00/d00 exists before you close without saving.  Do the close
>> without saving in HEAD, with its failed, incomplete cleanup.  Is e00 still
>> present but e00/d00 removed?
>>
>> If that is so, then this would suggest to me that Audacity did in fact
>> successfully find and remove the lowest-level folder, but the removal of it
>> is somehow asynchronously completed on Sierra, and Audacity should pause a
>> bit after removing each folder, before trying to remove its parent.  There
>> may be many folders, so this must be a small pause at most, but maybe only a
>> few milliseconds after each is what we need.
>>
>> PRL
>>
>>
>>>
>>>
>>>
>>>>
>>>>
>>>> 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.
>>>>
>>>>>
>>>>>
>>>>>
>>>>> > 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.
>>>>
>>>>
>>>> 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
>>>>
>>>>>
>>>>>
>>>>>
>>>>> > 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
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> 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
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>
>>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
12
Loading...