Re: [Finale] File Overwrite Bug in Action

[David W. Fenton]

On 26 Jan 2005 at 16:04, Jari Williamsson wrote:

> Darcy James Argue wrote:
> 
> > I haven't tried cmd-shift-D, but last time I had the problem, I
> > noticed it *before* closing windows because, although the displayed
> > file was correct, printing it resulted in printing a completely
> > different file.  Re-opening the same document from Finale's File
> > menu (without closing the first instance of the document) solved the
> > problem.  So there is clearly a "grace period" where the data can be
> > recovered if you notice what's going on and take the appropriate
> > steps.
> 
> Yes, the behaviour you describe is logical. The reason it's the
> correct file that's displaying is because of Finale's display buffers.
> What's actually displayed in the window is a picture of the "correct"
> document, while when printing all data is retrieved from the document
> database itself. Zooming in/out or switching between scroll/page view
> should also rebuild the display buffer, btw (=show the actual document
> contents).

What would the document window show as its title before and after the 
redraw -- the display filename or the data filename?

In the cases I've had the problem, it was always the wrong data 
displayed for the filename in the document window's title bar. Redraw 
did not correct it the times I tried it (which was not every time I 
encountered the bug). I didn't save or print the files, so I don't 
really know what was *really* behind the displayed data.

-- 
David W. Fentonhttp://www.bway.net/~dfenton
David Fenton Associateshttp://www.bway.net/~dfassoc

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[laloba2]

Well, this is good to know!  Maybe because more than one person was 
working on a server when this happened in my situation, the files 
were being saved before anyone noticed what was going on.  But this 
is good to know.  I will definitely try this next time if it happens 
again and pass the info along!

:-)
Thank you Christopher, Darcy and Jari!
-K
On 26 Jan 2005, at 12:07 AM, [EMAIL PROTECTED] wrote:
The thing is...and maybe someone can either affirm or deny this for 
sure...on the Mac platform, the file is actually overwritten 
permanently rather than what happens in Windows if I am 
understanding correctly i.e. the information in the window being 
incorrect but not Command+Shift+D will restore it as you mentioned.
I haven't tried cmd-shift-D, but last time I had the problem, I 
noticed it *before* closing windows because, although the displayed 
file was correct, printing it resulted in printing a completely 
different file.  Re-opening the same document from Finale's File 
menu (without closing the first instance of the document) solved the 
problem.  So there is clearly a "grace period" where the data can be 
recovered if you notice what's going on and take the appropriate 
steps.

Cheers,
- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

--
Karen Guthery
[EMAIL PROTECTED]
ichat: [EMAIL PROTECTED]
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Christopher Smith]

This sounds right to me, as far as I can tell. When I have saved the 
file, it saves with the wrong contents. If I change to Scroll View, or 
redraw, or update, the proper contents seem to come back.

Weird.
Christopher
On Wednesday, January 26, 2005, at 09:04  AM, Darcy James Argue wrote:
On 26 Jan 2005, at 12:07 AM, [EMAIL PROTECTED] wrote:
The thing is...and maybe someone can either affirm or deny this for 
sure...on the Mac platform, the file is actually overwritten 
permanently rather than what happens in Windows if I am understanding 
correctly i.e. the information in the window being incorrect but not 
Command+Shift+D will restore it as you mentioned.
I haven't tried cmd-shift-D, but last time I had the problem, I 
noticed it *before* closing windows because, although the displayed 
file was correct, printing it resulted in printing a completely 
different file.  Re-opening the same document from Finale's File menu 
(without closing the first instance of the document) solved the 
problem.  So there is clearly a "grace period" where the data can be 
recovered if you notice what's going on and take the appropriate > steps.

Cheers,
- Darcy

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Jari Williamsson]

Darcy James Argue wrote:
I haven't tried cmd-shift-D, but last time I had the problem, I noticed 
it *before* closing windows because, although the displayed file was 
correct, printing it resulted in printing a completely different file.  
Re-opening the same document from Finale's File menu (without closing 
the first instance of the document) solved the problem.  So there is 
clearly a "grace period" where the data can be recovered if you notice 
what's going on and take the appropriate steps.
Yes, the behaviour you describe is logical. The reason it's the correct 
file that's displaying is because of Finale's display buffers. What's 
actually displayed in the window is a picture of the "correct" document, 
while when printing all data is retrieved from the document database itself.
Zooming in/out or switching between scroll/page view should also rebuild 
the display buffer, btw (=show the actual document contents).

Best regards,
Jari Williamsson
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Allen Fisher]

I don't think this is the same thing, because  I seem to remember him saying
that a redraw corrects, or maybe it's my jet lag talking.


On 1/23/05 8:49 AM, "Christopher Smith" <[EMAIL PROTECTED]>
wrote:

> 
> On Jan 21, 2005, at 6:20 PM, David W. Fenton wrote:
> 
>> On 21 Jan 2005 at 23:15, Jari Williamsson wrote:
>> 
>>> A-NO-NE Music wrote:
>>> 
 Someone pointed out the bug seems to be caused by the array pointer,
 and I have the same feeling.
>>> 
>>> As I've said earlier when this have been discussed, the window
>>> handle/ID starts to map to the wrong Enigma Doc ID. I think that's
>>> pretty obvious, but of course that doesn't explain _why_ it happens
>>> and only seem to happen on the Mac.
>> 
>> But it *has* happened to *me* on Windows -- I've never lost data, but
>> as I've said many times, I've seen the wrong data displayed for the
>> window titles (i.e., document names).
>> 
>> 
> 
> Well, that's the bug! Can you weigh in with what you were doing when
> the bug hit? Are there certain circumstances when it happens that you
> can identify? Do any of the things we have mentioned ring a bell, like
> opening a new file while several others are already open, changing a
> text block, and saving it (which is what I did to invoke the bug in
> every instance I can remember?) Your deeper computer knowledge could
> really help out here.
> 
> Christopher
> 
> ___
> Finale mailing list
> Finale@shsu.edu
> http://lists.shsu.edu/mailman/listinfo/finale

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Darcy James Argue]

On 26 Jan 2005, at 12:07 AM, [EMAIL PROTECTED] wrote:
The thing is...and maybe someone can either affirm or deny this for 
sure...on the Mac platform, the file is actually overwritten 
permanently rather than what happens in Windows if I am understanding 
correctly i.e. the information in the window being incorrect but not 
Command+Shift+D will restore it as you mentioned.
I haven't tried cmd-shift-D, but last time I had the problem, I noticed 
it *before* closing windows because, although the displayed file was 
correct, printing it resulted in printing a completely different file.  
Re-opening the same document from Finale's File menu (without closing 
the first instance of the document) solved the problem.  So there is 
clearly a "grace period" where the data can be recovered if you notice 
what's going on and take the appropriate steps.

Cheers,
- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[laloba2]

(from Jari's reply to Christopher)
The questions was because it's the connection between the doc window 
and the enigma document database that malfunctions before the 
overwrite bug strikes. And I would assume that the first place to 
look would be at places that in some way access the table (or array 
or collection or whatever the tecnical term might be in this case) 
that handles the mapping.
When this happens would most probably be when document windows are 
opened/closed or when dowcument windows are switched.
Plug-ins have limited access to this info as well (in Fin2003 I was 
able to cause a similar problem myself by writing a buggy plug-in).
Hi Jari,
I have been doing some reading and what you are saying here jibes 
(there's that word again) with some of the things I have been 
reading...So for those of us on the list with insomnia, here they 
are...


This part interested me... "One particular problem often arises when 
there is more than one pointer to a specific block. If the first 
entity owns the memory and wants to free it, then it must first 
consider whether any other pointers point at that location. If any 
do, and the first entity frees the memory, those other pointers 
become dangling pointers-pointers that point to space that is no 
longer valid. When the dangling pointer is used, you may happen to 
get the correct data, but eventually the memory will be reused (via 
another call to malloc()) leading to unpleasant interactions between 
the dangling pointer and the new owner of that piece of memory. A 
dangling pointer is the opposite of a leak."

So, in a low memory situation, memory will be reused more quickly as 
the system grasps for whatever it can get a hold of.  Does this make 
sense?

This link is very interesting!! 



The above is an older article...so some of it is obsolete but many of 
the concepts still apply I believe.  See heap fragmentation, dangling 
pointers, invalid handles (I think handles are now called events in 
OS X...but not completely sure) and low memory conditions.

"
This is why OS X uses so much memory (from the above link):  " Also, 
Mac OS X tends to eat up all available memory, even if there is a lot 
of it available. This is because Mac OS X caches as much data as it 
can in memory, so that it can potentially reuse that data without 
having to re-cache it (the UNIX term for caching data in memory is 
"paging in" memory). Mac OS X's performance drops when all available 
memory is used, because it has to start removing things from memory 
("paging out"), which has a performance hit. This problem is much 
more prevalent in Mac OS X because applications are not limited to a 
specific amount of memory; they just take as much as they need, so 
free memory dwindles fast."

An "interesting" thing about the bug (based on the reports I've 
seen) here is that it always seems to point at another existing 
document database, never to a "wild" value.
This interests me too
Anyway, I think you can avoid to get files overwritten by pressing 
Command+Shift+D (unsure about the keystroke here for the Mac, it 
should be the keystroke for "redraw" with the "Shift" key added to 
it) before saving the file.
In Mac this is command-D :-)
That will refresh the window contents based on the current data 
connected to the window (it will not use any buffers like "redraw" 
does). That should at least make it possible to assure that it's the 
correct data that will be written to the file.
I haven't tried this when the bug bites but if it happens again I 
certainly will try it..  What I have been doing is NOT saving 
documents in order to not corrupt the backups.  Then I go to the 
backup folder and replace the files that have been overwritten with 
the intact backups.

The thing is...and maybe someone can either affirm or deny this for 
sure...on the Mac platform, the file is actually overwritten 
permanently rather than what happens in Windows if I am understanding 
correctly i.e. the information in the window being incorrect but not 
Command+Shift+D will restore it as you mentioned.

Thanks Jari...I'm curious to hear if any of this rings a bell for you..
-K
--
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[laloba2]

On Jan 23, 2005, at 12:27 PM, [EMAIL PROTECTED] wrote:
That should help...also,
Do you mind telling me how much RAM you have in your computer?  You 
can do this off list if you prefer.  Thanks.  I'm trying to get a 
idea of what sorts of machines this is happening on...especially 
memory specs.
I'm not 100% sure what you're asking for, but my "Hardware Overview" 
under "System Profiler", says this:

  Machine Model:PowerBook G4 15"
  CPU Type: PowerPC G4  (1.1)
  Number Of CPUs:   1
  CPU Speed:1 GHz
  L2 Cache (per CPU):   512 KB
  Memory:   256 MB
  Bus Speed:167 MHz
  Boot ROM Version: 4.7.1f1
Does that answer your question?

Yes, thanks Mark. :-)  I think the symptoms you were mentioning in 
your previous posts were in fact because you have very little RAM in 
the machine...but I saw your reply post to Darcy and if you are doing 
fine with the system as it is...then all is well :-)

Thanks again,
-K
--
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[laloba2]

On 24 Jan 2005 at 22:45, Darcy James Argue wrote:
 On 24 Jan 2005, at 7:39 PM, David W. Fenton wrote:
 > Has Darcy reported low memory as a part of his problems?
 That's hard to say.  I had 768 MB of RAM in my old Mac, but I also
 routinely run Mail and Safari and iKey and DragThing and RealPlayer
 and iTunes along with Finale, and I often have 20+ windows open in
 Finale, and a whole bunch of tabs open in Safari.  So yes, I expect
 > memory was tight pretty much every time I encountered this bug.

Well, that's not really my definition of "tight" when you have 768MBs
of real RAM, unless most of the programs you're running are bad
memory hogs/leakers. I have routinely run a configuration on Windows
similar to that for years, even before I had 786MBs of RAM on my own
machine.
Actually, I think Darcy is right...Having all the applications open 
he mentioned and that many windows open would definitely cause memory 
to be "tight"...at least on a Macintosh.  I suggest to my clients 
that they have a minimum of 512MBs RAM on their OS X Machines.  Apple 
reAnd more if they are running several apps at a time and especially 
some of the more memory intensive apps I suggest starting with at 
least 1GB.  I have 2GB's in my G5 and that is the low side of what I 
should have considering some of the applications I run on that 
machine.

If you're running out of memory in those configurations, then one or
more of those programs is being very inefficient in its memory usage.
That's not necessarily true.  I would expect the kind of work load 
that Darcy is talking about to put that kind of stress on system 
resources on a Macintosh.

-K
--
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[David W. Fenton]

On 24 Jan 2005 at 22:45, Darcy James Argue wrote:

> On 24 Jan 2005, at 7:39 PM, David W. Fenton wrote:
> 
> > Has Darcy reported low memory as a part of his problems?
> 
> That's hard to say.  I had 768 MB of RAM in my old Mac, but I also
> routinely run Mail and Safari and iKey and DragThing and RealPlayer
> and iTunes along with Finale, and I often have 20+ windows open in
> Finale, and a whole bunch of tabs open in Safari.  So yes, I expect
> memory was tight pretty much every time I encountered this bug.

Well, that's not really my definition of "tight" when you have 768MBs 
of real RAM, unless most of the programs you're running are bad 
memory hogs/leakers. I have routinely run a configuration on Windows 
similar to that for years, even before I had 786MBs of RAM on my own 
machine.

If you're running out of memory in those configurations, then one or 
more of those programs is being very inefficient in its memory usage.

And even if Finale is the offender here, that still doesn't tie in 
low memory as the cause of the file overwrite bug.

-- 
David W. Fentonhttp://www.bway.net/~dfenton
David Fenton Associateshttp://www.bway.net/~dfassoc

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Mark D Lew]

On Jan 24, 2005, at 10:50 PM, Darcy James Argue wrote:
I would suggest adding (at least) another 256 MB of RAM to your 
PowerBook.  You will notice a considerable difference.
Enh, you know me.  I have simple needs, and I'm not the sort of person 
who craves speed.  I don't perceive any problem with the computer as 
is.  It works OK, and I don't mind having to reboot once or twice a 
week.  On the rare occasion that something seems a little slow, I'm 
happy to have a spare moment to relax and reflect.

What little drive I have for souping up my computer will be devoted to 
more rudimentary needs.  (I still haven't gotten that CD drive 
fixed)

mdl
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Jari Williamsson]

Christopher Smith wrote:
On Jan 23, 2005, at 4:54 AM, Jari Williamsson wrote:
Here are some more thoughts:
* Have you closed any documents prior to when the bug occurs?
Always.
* Have you had multiple windows for the same document opened?
Not me, in this case.
* Has any plug-ins been run that support multiple docs (Settings 
Scrapbook, FinaleScript, Text Search & Replace, etc)?

Again, not with me.
I'm not sure why those questions are important, though.
The questions was because it's the connection between the doc window and 
the enigma document database that malfunctions before the overwrite bug 
strikes. And I would assume that the first place to look would be at 
places that in some way access the table (or array or collection or 
whatever the tecnical term might be in this case) that handles the mapping.
When this happens would most probably be when document windows are 
opened/closed or when dowcument windows are switched.
Plug-ins have limited access to this info as well (in Fin2003 I was able 
to cause a similar problem myself by writing a buggy plug-in).

An "interesting" thing about the bug (based on the reports I've seen) 
here is that it always seems to point at another existing document 
database, never to a "wild" value.

Anyway, I think you can avoid to get files overwritten by pressing 
Command+Shift+D (unsure about the keystroke here for the Mac, it should 
be the keystroke for "redraw" with the "Shift" key added to it) before 
saving the file. That will refresh the window contents based on the 
current data connected to the window (it will not use any buffers like 
"redraw" does). That should at least make it possible to assure that 
it's the correct data that will be written to the file.

Best regards,
Jari Williamsson
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Darcy James Argue]

Hi Mark,
With only 256 MB of RAM on your machine, memory is likely to be tight 
even with only a single application open at any one time.  OS X's 
memory demands are considerable, and most people do not believe that 
256 MB of physical RAM is sufficient even for casual, everyday use.

I would suggest adding (at least) another 256 MB of RAM to your 
PowerBook.  You will notice a considerable difference.

- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY
On 25 Jan 2005, at 12:35 AM, Mark D Lew wrote:
On Jan 23, 2005, at 12:27 PM, [EMAIL PROTECTED] wrote:
That should help...also,
Do you mind telling me how much RAM you have in your computer?  You 
can do this off list if you prefer.  Thanks.  I'm trying to get a 
idea of what sorts of machines this is happening on...especially 
memory specs.
I'm not 100% sure what you're asking for, but my "Hardware Overview" 
under "System Profiler", says this:

  Machine Model:PowerBook G4 15"
  CPU Type: PowerPC G4  (1.1)
  Number Of CPUs:   1
  CPU Speed:1 GHz
  L2 Cache (per CPU):   512 KB
  Memory:   256 MB
  Bus Speed:167 MHz
  Boot ROM Version: 4.7.1f1
Does that answer your question?
mdl
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Mark D Lew]

On Jan 23, 2005, at 12:27 PM, [EMAIL PROTECTED] wrote:
That should help...also,
Do you mind telling me how much RAM you have in your computer?  You 
can do this off list if you prefer.  Thanks.  I'm trying to get a idea 
of what sorts of machines this is happening on...especially memory 
specs.
I'm not 100% sure what you're asking for, but my "Hardware Overview" 
under "System Profiler", says this:

  Machine Model:PowerBook G4 15"
  CPU Type: PowerPC G4  (1.1)
  Number Of CPUs:   1
  CPU Speed:1 GHz
  L2 Cache (per CPU):   512 KB
  Memory:   256 MB
  Bus Speed:167 MHz
  Boot ROM Version: 4.7.1f1
Does that answer your question?
mdl
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Mark D Lew]

On Jan 23, 2005, at 8:22 PM, [EMAIL PROTECTED] wrote:
I just looked back at a couple of posts one from Chuck and one from 
Mark.  Chuck mentioned that his system seemed to start to slow down 
after a long Finale session and that is when the icon for the selected 
tool in the tool palette turns into the Finale icon.  (I've had this 
happen to me too.)  Mark had a similar thing happening with icons 
appearing incorrectlywith the wrong graphic and then a garbled 
graphic.  His system was also in the state where it seemed that memory 
was "tight" as he put it.
If that's what you got from my post, I may not have been clear.
First of all, I didn't suggest that this has anything at all with 
Finale.  I actually haven't used Finale very much over the past few 
months, and when I do use it, I tend to use it alone -- ie, not 
simultaneous with many other applications -- and then close it when I'm 
done.

As for my comment that memory seemed "tight", that was my speculation 
(perhaps incorrect) based on the symptoms I described -- ie, messed up 
icons and, later, things that wouldn't open or display at all.  I don't 
have a deep understanding of how computers work, but from my vague 
layman experience over the years I have the general impression that 
things like that happen when memory is running low.  But I don't really 
know.

I definitely did not mean to suggest that memory was tight because I 
had a lot of applications running.  As I mentioned, my usual habit is 
to close down applications when I'm not using them, so I'm rarely 
taxing the memory in that way.  I was responding to your comment about 
Safari "leaking" memory, thinking that my system shows symptoms which 
are possibly caused by low memory (eg, icons, etc) even though I 
*don't* have the obvious causes of low memory (ie, lots of applications 
open).

By the way, I just thought of something else that may or may not 
related.  A while back I started using "disk images" as another way of 
organizing archived files.  Maybe it's just my quirky filing 
preferences, but I like having some files packed away in a separate 
container where they don't show up separately on my hard drive but can 
still be easily accessed by opening the dmg file.  I'm not sure what 
exactly these disk images do under the hood, but maybe that's related 
to a memory problem.  I haven't paid attention enough to see if my 
symptoms are correlated to whether I have a disk image open.

mdl
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Darcy James Argue]

On 24 Jan 2005, at 7:39 PM, David W. Fenton wrote:
Has Darcy reported low memory as a part of his problems?
That's hard to say.  I had 768 MB of RAM in my old Mac, but I also 
routinely run Mail and Safari and iKey and DragThing and RealPlayer and 
iTunes along with Finale, and I often have 20+ windows open in Finale, 
and a whole bunch of tabs open in Safari.  So yes, I expect memory was 
tight pretty much every time I encountered this bug.

And if low memory is the *cause*, it, of necessity, must be present
every time the bug hits.
I don't know if low memory/stressed system resources is the *cause* of 
the File Overwrite bug, but I think it's safe to say that memory is 
probably tight pretty much every time I use Finale.  Also that, in my 
experience, the File Overwrite bug tends to strike only after several 
hours of using Finale.

The other thing is that my old machine was a total FrankenMac -- it was 
originally a 266 MHz Beige G3 which I bought back in 1998, before the 
introduction of the first iMac.  But almost nothing in it now is stock. 
 I replaced the processor (three times -- most recently with a 1 GHz G4 
from Sonnet), the memory (768 MB RAM), the hard drive (30 GB Maxtor) 
optical drive (Toshiba DVD-ROM), video card (Radeon 7000), added a PCI 
FireWire/USB card, Bluetooth module, Wet11 WiFi Ethernet bridge, 
M-Audio FireWire Audiophile MIDI/Audio breakout box, etc etc etc.  
Unlike stock Macs, this mishmash of third-party components was not 
designed to work seamlessly together, and I'm fairly certain that at 
least some of the stability problems I've been having with Fin2004-2005 
(crashing, etc -- probably *not* the file overwrite bug, though... ) 
has to do with my absurdly nonstandard setup.

- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[David W. Fenton]

On 23 Jan 2005 at 20:22, [EMAIL PROTECTED] wrote:

[quoting me:]
> >On 22 Jan 2005 at 21:31, [EMAIL PROTECTED] wrote:
> >
> >>  My theory is that at this point, there is a problem with the way
> >>  Finale has been programmed. . . .
> >
> >I think *that's* indisputable!
> >
> >>  . . . A problem, which results in the Overwrite
> >>  Bug, that when there is more memory in a machine, doesn't occur.
> >>  But when there isn't enough memory and the system gets to the
> >>  point of thrashing, then the mistakes made in the way that Finale
> >>  was written result in this problem.
> >
> >I don't know that anyone has identified low memory as a requirement
> >to produce the bug.
> 
> That is true...no one has identified that for sure.   But given the
> way the machines act about the time the bug bites, and Christopher at
> least has said that it has never happened to him on a newly booted
> machine, to me, it seems possible that there may be a correlation
> between memory and this bug...but I'm also just speculating :-)

I think you're mixing unrelated reports (see below).

> >>  Can you think of anything in the way a program is coded that would
> >>  fit into this scenario and possibly cause the overwrite bug?
> >>  Problems with the way the program uses threads?  I/O issues?
> >>  Caching?  etc?
> >
> >I can't think of a reason why low memory could suddenly cause
> >corruption of such a minor type. When a program can't handle low
> >memory conditions, usually the results are fairly catastrophic.
> 
> Well, for those that are losing the work, it can be catastrophic!! :-)

Well, yes, from a human point of view that's catastrophic, but Finale 
cannot tell that there is corruption of data, because it's not 
*structural* corruption, but content corruption. That kind of 
corruption simply can't happen from something like virtual memory 
problems because it's not a random enough result.

>  And I think that Christopher mentioned that after the bug hit on his
> machine, Finale crashed shortly after that.

>From low memory or from some other cause?

> I just looked back at a couple of posts one from Chuck and one from
> Mark.  Chuck mentioned that his system seemed to start to slow down
> after a long Finale session and that is when the icon for the selected
> tool in the tool palette turns into the Finale icon.  (I've had this
> happen to me too.)  Mark had a similar thing happening with icons
> appearing incorrectlywith the wrong graphic and then a garbled
> graphic.  His system was also in the state where it seemed that memory
> was "tight" as he put it.

Were those reports of the file overwrite bug, or independent reports 
of low memory/performance problems.

Has Darcy reported low memory as a part of his problems?

And if low memory is the *cause*, it, of necessity, must be present 
every time the bug hits.

> >Of course, it depends on the type of low memory condition.
> 
> Can you elaborate here?

It depends on your definition of "low memory." Certain kinds of non-
RAM memory structures can run low and that gets reported as low 
memory (the details of that are specific to the OS and applications, 
though). Many times the term "low memory" is used when what is meant 
is "low system resources."

-- 
David W. Fentonhttp://www.bway.net/~dfenton
David Fenton Associateshttp://www.bway.net/~dfassoc

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Darcy James Argue]

Hi Jari,
FWIW, I have had the bug strike without doing any of these things.  I 
have also had the bug strike having done one or more of these things.

- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY
On 23 Jan 2005, at 4:54 AM, Jari Williamsson wrote:
Christopher Smith wrote:
Oh, we've tried! Here are some things that have cropped up, confirmed 
and unconfirmed by others:
[...]
Here are some more thoughts:
* Have you closed any documents prior to when the bug occurs?
* Have you had multiple windows for the same document opened?
* Has any plug-ins been run that support multiple docs (Settings 
Scrapbook, FinaleScript, Text Search & Replace, etc)?

Best regards,
Jari Williamsson
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[laloba2]

[EMAIL PROTECTED] / 05.1.23 / 05:32 PM wrote:
FreeBSDPanther is using FreeBSD 5.
Ha-ha.  Didn't know that :-)
It's kinda confusing since pre Jag had all the BSD man docs.  I actually
never installed FreeBSD I bought so I even don't know if BSD and FreeBSD
shares man docs.
Hiro, I'd love to hear more from you too about how Finale is using
memory...and this whole topic.  You seem to know much about this too
specific to OS X.  Are there any weaknesses you see that I was asking
David about?  Since none of us can come up with a specific user
action that causes the bug...at least not yet...
To my limited knowledge, as David pointed out, stressed memory cannot
corrupt anything.  The pref issue is something different.  There are two
types of pref architecture, one that keeps open, and the other opens only
when the app tries to log pref change.  I think Finale is latter, and it
seems pref change is cached until program exit.  Something goes sour,
pref r/w won't get executed.
That makes sense.
OSX's protected memory is very good.  I think our finger should point to
how Finale caches into its legacy temp file architecture.  But I am not a
real programmer, just a wannabe :-)
Well, I would still be curious about whatever direction you think 
this might be coming from...I'm not a programmer either...well not 
since the TRS-80 days  :-)...but you still know a lot about this.

(OK, my education was only java programming at Harvard, which sounds
impressive, but not a big deal at all, really.  Now you know I am not
that real!).
That's more programming than I have...:-)
Thanks Hiro-
-K
--
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[laloba2]

On 22 Jan 2005 at 21:31, [EMAIL PROTECTED] wrote:
 My theory is that at this point, there is a problem with the way
 Finale has been programmed. . . .
I think *that's* indisputable!
 . . . A problem, which results in the Overwrite
 Bug, that when there is more memory in a machine, doesn't occur.
 But when there isn't enough memory and the system gets to the point
 of thrashing, then the mistakes made in the way that Finale was
 written result in this problem.
I don't know that anyone has identified low memory as a requirement
to produce the bug.
That is true...no one has identified that for sure.   But given the 
way the machines act about the time the bug bites, and Christopher at 
least has said that it has never happened to him on a newly booted 
machine, to me, it seems possible that there may be a correlation 
between memory and this bug...but I'm also just speculating :-)


 Can you think of anything in the way a program is coded that would
 fit into this scenario and possibly cause the overwrite bug?
 Problems with the way the program uses threads?  I/O issues?
 Caching?  etc?
I can't think of a reason why low memory could suddenly cause
corruption of such a minor type. When a program can't handle low
memory conditions, usually the results are fairly catastrophic.

Well, for those that are losing the work, it can be catastrophic!! 
:-)  And I think that Christopher mentioned that after the bug hit on 
his machine, Finale crashed shortly after that.

I just looked back at a couple of posts one from Chuck and one from 
Mark.  Chuck mentioned that his system seemed to start to slow down 
after a long Finale session and that is when the icon for the 
selected tool in the tool palette turns into the Finale icon.  (I've 
had this happen to me too.)  Mark had a similar thing happening with 
icons appearing incorrectlywith the wrong graphic and then a 
garbled graphic.  His system was also in the state where it seemed 
that memory was "tight" as he put it.

Of course, it depends on the type of low memory condition.
Can you elaborate here?
I still don't think the memory issue really has anything to do with
it. When the OS is thrashing, Finale should just slow down to a
crawl, and, perhaps, stop.

Well, your input is much appreciated David.  Many thanks to you.
-K

--
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[David W. Fenton]

On 23 Jan 2005 at 19:18, A-NO-NE Music wrote:

> David W. Fenton / 05.1.23 / 06:56 PM wrote:
> 
> >Applications don't call the VM. The OS does, based on the memory
> >requirements of the applications the OS is running.
> 
> Perhaps you would elaborate why a huge chunk of vm is set when certain
> app is launched, while there are plenty of physical RAM is still
> available?

Well, if the VM is written to "plan ahead" that might explain it.

But it's not the app asking the VM for swap space, it's the VM 
reacting to the app's request for a certain amount of memory. That's 
a really crucial difference.

-- 
David W. Fentonhttp://www.bway.net/~dfenton
David Fenton Associateshttp://www.bway.net/~dfassoc

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[David W. Fenton]

On 22 Jan 2005 at 21:31, [EMAIL PROTECTED] wrote:

> My theory is that at this point, there is a problem with the way
> Finale has been programmed. . . .

I think *that's* indisputable!

> . . . A problem, which results in the Overwrite
> Bug, that when there is more memory in a machine, doesn't occur. 
> But when there isn't enough memory and the system gets to the point
> of thrashing, then the mistakes made in the way that Finale was
> written result in this problem.

I don't know that anyone has identified low memory as a requirement 
to produce the bug.  

> Can you think of anything in the way a program is coded that would
> fit into this scenario and possibly cause the overwrite bug?
> Problems with the way the program uses threads?  I/O issues?
> Caching?  etc?

I can't think of a reason why low memory could suddenly cause 
corruption of such a minor type. When a program can't handle low
memory conditions, usually the results are fairly catastrophic.

Of course, it depends on the type of low memory condition.

I still don't think the memory issue really has anything to do with 
it. When the OS is thrashing, Finale should just slow down to a 
crawl, and, perhaps, stop.  

But all that I'm writing here is mere speculation as I don't know the
conditions necessary to produce the bug. All I know is that I think
this is the least likely cause of the problem because the symptoms do
not match up with this kind of root cause.

-- 
David W. Fentonhttp://www.bway.net/~dfenton
David Fenton Associateshttp://www.bway.net/~dfassoc

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[David W. Fenton]

On 23 Jan 2005 at 11:49, Christopher Smith wrote:

> On Jan 21, 2005, at 6:20 PM, David W. Fenton wrote:
> 
> > On 21 Jan 2005 at 23:15, Jari Williamsson wrote:
> >
> >> A-NO-NE Music wrote:
> >>
> >>> Someone pointed out the bug seems to be caused by the array
> >>> pointer, and I have the same feeling.
> >>
> >> As I've said earlier when this have been discussed, the window
> >> handle/ID starts to map to the wrong Enigma Doc ID. I think that's
> >> pretty obvious, but of course that doesn't explain _why_ it happens
> >> and only seem to happen on the Mac.
> >
> > But it *has* happened to *me* on Windows -- I've never lost data,
> > but as I've said many times, I've seen the wrong data displayed for
> > the window titles (i.e., document names).
> 
> Well, that's the bug! Can you weigh in with what you were doing when
> the bug hit? . . .

It has happened so seldom, and in some cases so long ago (it was in 
WinFin97, which haven't been using since August 2002) that I simply 
don't remember any of the conditions.

> . . . Are there certain circumstances when it happens that you
> can identify? Do any of the things we have mentioned ring a bell, like
> opening a new file while several others are already open, changing a
> text block, and saving it (which is what I did to invoke the bug in
> every instance I can remember?) Your deeper computer knowledge could
> really help out here.

I have nothing to offer here. It hasn't happened to me lately, but 
that's because I'm not using Finale heavily these days.

Also, it's unlikely to happen to me because I almost never edit more 
than one file at a time.

-- 
David W. Fentonhttp://www.bway.net/~dfenton
David Fenton Associateshttp://www.bway.net/~dfassoc

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[David W. Fenton]

On 23 Jan 2005 at 1:59, A-NO-NE Music wrote:

> David W. Fenton / 05.1.22 / 07:37 PM wrote:
> 
> >Mac users are probably confused about virtual memory because of the
> >way it was bolted onto Mac OS as an extension that often conflicted
> >with applications.
> >
> >You're now living in a completely different world, one where the apps
> > don't know anything about managing system memory at all. They only
> >know about their own memory requirements.
> >
> >Keep in mind that under OS X you don't have to set the amount of
> >memory to be allocated to an application (as was the case with Mac
> >OS). This is a direct indication of the fact that memory management
> >is now wholly owned by the operating system itself.
> 
> 
> I don't think you understood me.  You seems to think I was talking
> about Classic Mac OSes, while you are clearly based on NT 
> Kernel. . . .

Eh? What are you talking about? Windows NT? What does that have to do 
with Mac OS?

I'm talking about OS's in general, not about the specific 
architecture of any particular virtual memory manager.

> . . . Did
> you know OSX blocks swapfile allocation in 67.1MB each for first two,
> then size multiplies after, i.e., the 3rd is about 135MB, and the 4th
> is about 268MB, and so on.?  It's not like NT Kernel does at all. 

Only in implementation details is it different (and I'd wager that 
the increment size is something that can be changed). In the basics 
of interaction between VM and applications, it's pretty much the 
same: applications can't move while the VM is paging.

> And, as I said before, there are some apps that calls vm at launch,
> and the vm size never changes after that regardless of the presence of
> available physical memory and the size of the project file.

Applications don't call the VM. The OS does, based on the memory 
requirements of the applications the OS is running.

> And to your other post, as far as I know, OSX did not take vm
> architecture from BSD kernel, which was the base design of Darwin
> Kernel.

But virtual memory subsystems have certain things in common or they 
wouldn't be virtual memory subsystems. One thing that is common to 
all real VMs is that applications don't even know they exist.

-- 
David W. Fentonhttp://www.bway.net/~dfenton
David Fenton Associateshttp://www.bway.net/~dfassoc

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[A-NO-NE Music]

[EMAIL PROTECTED] / 05.1.23 / 05:32 PM wrote:

>FreeBSDPanther is using FreeBSD 5.

Ha-ha.  Didn't know that :-)
It's kinda confusing since pre Jag had all the BSD man docs.  I actually
never installed FreeBSD I bought so I even don't know if BSD and FreeBSD
shares man docs.

>Hiro, I'd love to hear more from you too about how Finale is using 
>memory...and this whole topic.  You seem to know much about this too 
>specific to OS X.  Are there any weaknesses you see that I was asking 
>David about?  Since none of us can come up with a specific user 
>action that causes the bug...at least not yet...

To my limited knowledge, as David pointed out, stressed memory cannot
corrupt anything.  The pref issue is something different.  There are two
types of pref architecture, one that keeps open, and the other opens only
when the app tries to log pref change.  I think Finale is latter, and it
seems pref change is cached until program exit.  Something goes sour,
pref r/w won't get executed.

OSX's protected memory is very good.  I think our finger should point to
how Finale caches into its legacy temp file architecture.  But I am not a
real programmer, just a wannabe :-)
(OK, my education was only java programming at Harvard, which sounds
impressive, but not a big deal at all, really.  Now you know I am not
that real!).

-- 

- Hiro

Hiroaki Honshuku, A-NO-NE Music, Boston, MA
 


___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[laloba2]

[EMAIL PROTECTED] / 05.1.23 / 05:14 PM wrote:
Apple's Darwin kernel is based on FreeBSD

I thought it was BSD, not FreeBSD, no?
FreeBSDPanther is using FreeBSD 5.
Hiro, I'd love to hear more from you too about how Finale is using 
memory...and this whole topic.  You seem to know much about this too 
specific to OS X.  Are there any weaknesses you see that I was asking 
David about?  Since none of us can come up with a specific user 
action that causes the bug...at least not yet...

:-)
-K
--
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[A-NO-NE Music]

[EMAIL PROTECTED] / 05.1.23 / 05:14 PM wrote:

>Apple's Darwin kernel is based on FreeBSD


I thought it was BSD, not FreeBSD, no?


-- 

- Hiro

Hiroaki Honshuku, A-NO-NE Music, Boston, MA
 


___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[laloba2]

David W. Fenton / 05.1.22 / 07:37 PM wrote:
Mac users are probably confused about virtual memory because of the
way it was bolted onto Mac OS as an extension that often conflicted
with applications.
You're now living in a completely different world, one where the apps
don't know anything about managing system memory at all. They only
know about their own memory requirements.
Keep in mind that under OS X you don't have to set the amount of
memory to be allocated to an application (as was the case with Mac
OS). This is a direct indication of the fact that memory management
is now wholly owned by the operating system itself.

I don't think you understood me.  You seems to think I was talking about
Classic Mac OSes, while you are clearly based on NT Kernel.  Did you know
OSX blocks swapfile allocation in 67.1MB each for first two, then size
multiplies after, i.e., the 3rd is about 135MB, and the 4th is about
268MB, and so on.?  It's not like NT Kernel does at all.  And, as I said
before, there are some apps that calls vm at launch, and the vm size
never changes after that regardless of the presence of available physical
memory and the size of the project file.
And to your other post, as far as I know, OSX did not take vm
architecture from BSD kernel, which was the base design of Darwin Kernel.
right.VM didn't come from the BSD kernelit comes from Mach VM 
but has been enhanced.  But OS X VM does still support Universal Page 
lists.  Apple's Darwin kernel is based on FreeBSD

Oh, and when OSX runs out of physical memory and vm space, it will warn
you that you need to exit open applications to free up the memory space,
but it will continue to run with, as you said, slow performance if one
ignores the warning :-)
--
- Hiro
Hiroaki Honshuku, A-NO-NE Music, Boston, MA
 
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

--
Karen Guthery
[EMAIL PROTECTED]
ichat: [EMAIL PROTECTED]
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Aaron Sherber]

At 12:28 PM 01/23/2005, A-NO-NE Music wrote:
>Not on Word Mac version.  If you try to open the same doc, it will
>replace the open one.  In the effect, it does Revert to Saved.
Not *open* the same doc, just a new window. In WinWord, I can do Window | 
New Window, which is exactly the same menu command as WinFin, and does the 
same thing.

>How do you expect to track with which window is the current of the same
>document?
They're both current -- changes you make in one window are reflected in the 
other as well.

Aaron. 

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[laloba2]

On Jan 23, 2005, at 1:08 AM, [EMAIL PROTECTED] wrote:
[answering Christopher Smith]

Safari leaks memory?
I don't think it does anymorebut it was a problem as far as I 
know up until 10.3.5 and possibly 10.3.6.  But I'm hearing that 
this was fixed in 10.3.7.

I'm not exactly a computer geek, so I don't know what this means.
It is when an application, because of a bug, fails to return it's 
memory back to the OS once it is no longer needed or when it is 
very inefficient in the way that it uses memory.  So over time, 
more RAM is used up than necessary...
I'm not a computer geek either, but I think I may be experiencing 
that.  I'm on OS 10.3.4 on a lightly loaded PowerBook G4.  There's 
only about a dozen applications I use regularly, and they're all 
pretty basic.  I use Safari a lot.  My personal computer habit is 
that I almost always close applications when I'm not using them, but 
I almost never shut down the computer.

I've noticed that I need to restart the computer about every four or 
five days due to what appears to tightness of memory.  I usually see 
it first in icons appearing incorrectly -- first with the wrong 
picture, then with a corrupted picture, then not showing up at all. 
When it reaches the last phase, sometimes certain applications won't 
launch at all.  (I think there were a few other weird things that 
happen at this phase )

Closing all the applications does not solve the problem.  Restarting 
the compute always does.

Now that you mention this, next time I'm somewhere with a fast 
wireless connection, I'll do a software update and get my OS up to 
10.3.whatever is latest, and I'll see if that makes the problem go 
away.

mdl
Hi Mark,
That should help...also,
Do you mind telling me how much RAM you have in your computer?  You 
can do this off list if you prefer.  Thanks.  I'm trying to get a 
idea of what sorts of machines this is happening on...especially 
memory specs.

-K
--
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Mark D Lew]

On Jan 23, 2005, at 1:08 AM, [EMAIL PROTECTED] wrote:
[answering Christopher Smith]
Safari leaks memory?
I don't think it does anymorebut it was a problem as far as I know 
up until 10.3.5 and possibly 10.3.6.  But I'm hearing that this was 
fixed in 10.3.7.

I'm not exactly a computer geek, so I don't know what this means.
It is when an application, because of a bug, fails to return it's 
memory back to the OS once it is no longer needed or when it is very 
inefficient in the way that it uses memory.  So over time, more RAM is 
used up than necessary...
I'm not a computer geek either, but I think I may be experiencing that. 
 I'm on OS 10.3.4 on a lightly loaded PowerBook G4.  There's only about 
a dozen applications I use regularly, and they're all pretty basic.  I 
use Safari a lot.  My personal computer habit is that I almost always 
close applications when I'm not using them, but I almost never shut 
down the computer.

I've noticed that I need to restart the computer about every four or 
five days due to what appears to tightness of memory.  I usually see it 
first in icons appearing incorrectly -- first with the wrong picture, 
then with a corrupted picture, then not showing up at all.  When it 
reaches the last phase, sometimes certain applications won't launch at 
all.  (I think there were a few other weird things that happen at this 
phase )
Closing all the applications does not solve the problem.  Restarting 
the compute always does.

Now that you mention this, next time I'm somewhere with a fast wireless 
connection, I'll do a software update and get my OS up to 10.3.whatever 
is latest, and I'll see if that makes the problem go away.

mdl
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Richard Yates]

> >So you can easily copy music from one part of a document to another, for
> >example, by having two windows open and visible. This is not unusual;
Word
> >lets you do the same thing.
>
>
> Not on Word Mac version.  If you try to open the same doc, it will
> replace the open one.  In the effect, it does Revert to Saved.

It is under Window --> Split  in Windows Word 2002.

RY


___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[A-NO-NE Music]

Jari Williamsson / 05.1.23 / 00:41 PM wrote:

>> Not on Word Mac version.  If you try to open the same doc, it will
>> replace the open one.  In the effect, it does Revert to Saved.
>
>In both Word and Finale (in Windows at least), you use "Window/New Window"

I see.
But Finale let you open the same doc with OS NAVServ as well.  Do you
think this can be a crucial step to reproduce the bug?  I never
encountered the bug, and I never knew Finale let you open multiple
windows of a doc.  I am too used to Shift+Opt+Click.

-- 

- Hiro

Hiroaki Honshuku, A-NO-NE Music, Boston, MA
 


___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Jari Williamsson]

A-NO-NE Music wrote:
Aaron Sherber / 05.1.23 / 11:33 AM wrote:

So you can easily copy music from one part of a document to another, for 
example, by having two windows open and visible. This is not unusual; Word 
lets you do the same thing.

Not on Word Mac version.  If you try to open the same doc, it will
replace the open one.  In the effect, it does Revert to Saved.
In both Word and Finale (in Windows at least), you use "Window/New Window"
How do you expect to track with which window is the current of the same
document?
Both windows update at the same time...
Best regards,
Jari Williamsson
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[A-NO-NE Music]

Aaron Sherber / 05.1.23 / 11:33 AM wrote:

>So you can easily copy music from one part of a document to another, for 
>example, by having two windows open and visible. This is not unusual; Word 
>lets you do the same thing.


Not on Word Mac version.  If you try to open the same doc, it will
replace the open one.  In the effect, it does Revert to Saved.

How do you expect to track with which window is the current of the same
document?

I just tried with Win version, and it does the same as Mac version.  Are
we talking about the same thing?


-- 

- Hiro

Hiroaki Honshuku, A-NO-NE Music, Boston, MA
 


___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Raymond Horton]

A-NO-NE Music wrote:
Jari Williamsson / 05.1.23 / 04:54 AM wrote:
 

* Have you had multiple windows for the same document opened?
   


I even didn't know this is possible.  I just tried, and sure enough,
Finale let you do this.  But why?
 

It's an easy way to copy sections of a piece to another part of the same 
piece, keeping both sections in view.  I use it all the time. 

Raymond Horton
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Christopher Smith]

On Jan 21, 2005, at 6:20 PM, David W. Fenton wrote:
On 21 Jan 2005 at 23:15, Jari Williamsson wrote:
A-NO-NE Music wrote:
Someone pointed out the bug seems to be caused by the array pointer,
and I have the same feeling.
As I've said earlier when this have been discussed, the window
handle/ID starts to map to the wrong Enigma Doc ID. I think that's
pretty obvious, but of course that doesn't explain _why_ it happens
and only seem to happen on the Mac.
But it *has* happened to *me* on Windows -- I've never lost data, but
as I've said many times, I've seen the wrong data displayed for the
window titles (i.e., document names).

Well, that's the bug! Can you weigh in with what you were doing when 
the bug hit? Are there certain circumstances when it happens that you 
can identify? Do any of the things we have mentioned ring a bell, like 
opening a new file while several others are already open, changing a 
text block, and saving it (which is what I did to invoke the bug in 
every instance I can remember?) Your deeper computer knowledge could 
really help out here.

Christopher
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Christopher Smith]

On Jan 23, 2005, at 4:54 AM, Jari Williamsson wrote:
Christopher Smith wrote:
Oh, we've tried! Here are some things that have cropped up, confirmed 
and unconfirmed by others:
[...]
Here are some more thoughts:
* Have you closed any documents prior to when the bug occurs?
Always.

* Have you had multiple windows for the same document opened?
Not me, in this case.

* Has any plug-ins been run that support multiple docs (Settings 
Scrapbook, FinaleScript, Text Search & Replace, etc)?


Again, not with me.
I'm not sure why those questions are important, though.
Christopher
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Aaron Sherber]

At 11:27 AM 01/23/2005, A-NO-NE Music wrote:
>Jari Williamsson / 05.1.23 / 04:54 AM wrote:
>
>>* Have you had multiple windows for the same document opened?
>
>
>I even didn't know this is possible.  I just tried, and sure enough,
>Finale let you do this.  But why?
So you can easily copy music from one part of a document to another, for 
example, by having two windows open and visible. This is not unusual; Word 
lets you do the same thing.

Aaron.
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[A-NO-NE Music]

Jari Williamsson / 05.1.23 / 04:54 AM wrote:

>* Have you had multiple windows for the same document opened?


I even didn't know this is possible.  I just tried, and sure enough,
Finale let you do this.  But why?


-- 

- Hiro

Hiroaki Honshuku, A-NO-NE Music, Boston, MA
 


___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Jari Williamsson]

Christopher Smith wrote:
Oh, we've tried! Here are some things that have cropped up, confirmed 
and unconfirmed by others:

[...]
Here are some more thoughts:
* Have you closed any documents prior to when the bug occurs?
* Have you had multiple windows for the same document opened?
* Has any plug-ins been run that support multiple docs (Settings 
Scrapbook, FinaleScript, Text Search & Replace, etc)?

Best regards,
Jari Williamsson
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[laloba2]

Safari leaks memory?
I don't think it does anymorebut it was a problem as far as I 
know up until 10.3.5 and possibly 10.3.6.  But I'm hearing that this 
was fixed in 10.3.7.


I'm not exactly a computer geek, so I don't know what this means.
It is when an application, because of a bug, fails to return it's 
memory back to the OS once it is no longer needed or when it is very 
inefficient in the way that it uses memory.  So over time, more RAM 
is used up than necessary...

Are you saying that if I get in the habit of quitting Safari when I 
am done, instead of just closing windows, that I might get around 
the paging thing?

I don't think I did a very good job of talking about this 
clearly...paging to an extent is normal.  It is a function of Virtual 
memory in the Mac OS X (for one but not the only OS that does 
this)...but you should read some of David's posts...he is much better 
at articulating this than I am...but, here's my best attempt:  when 
paging is excessive, it can be an indication of a shortage of 
RAM...the system will slow down and become sluggish...my theory, 
though not proven, but only a theory, is that when the system is in 
this state, the Overwrite Bug bites.  I don't think that this is a 
problem with OS X, but rather a weakness with Finale that only shows 
up when the computer is in this state.  But this is only a hunch.

So, here are some things that I think may help that I am going try in 
my own machine to see if it cuts down on the Overwrite Bug.  Some of 
them are general and good practices anyway

1)  Up the amount of RAM that is in the machine.
(If upping the RAM isn't an option or one doesn't want to do 
this...I'd suggest quitting any applications that aren't needed when 
running Finale, especially if several files are open at one time)
3) Restart the computer more often than one normally would...as Hiro mentioned.
4)  At any sign that the computer is getting sluggish, save all work 
and restart the computer.
5) Make sure cron scripts are running regularly...these may not be 
running if the computer is shut down or put to sleep overnight.  A 
program such as Cocktail or MacJanitor can be used to do this.

-K
--
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Christopher Smith]

On Jan 22, 2005, at 7:07 AM, Jari Williamsson wrote:
Perhaps it would be more productive if the Mac users who repeatedly 
experience this problem analyzed (in detail) what they did _prior_ to 
when the problem occured that is _different_ to what they do when it 
does _not_ happen. It can be any silly little thing along the way that 
matters here.

Oh, we've tried! Here are some things that have cropped up, confirmed 
and unconfirmed by others:

open text block in one of the open files (not confirmed)
text blocks in two different files have the same ID (how we might 
control or even identify this is beyond me)

the file comes from a previous version of Finale (100% true for every 
instance of the bug in my case, but I often work on old files with NO 
bug striking at all.)

I stop what I am doing with all the presently open files, open a 
different file in Finder by double-clicking on it, edit something 
(usually a text block) and save that file. When I go back to the other 
open files, the bug has struck. (this does NOT cause the bug even 5% of 
the time, but doing things like this seem to be risky behaviour.)

The concept of the system being stressed, or Finale having been running 
for a long time and building up a whole crop of temp files, is new to 
me, but entirely possible. I have never had the bug strike on a 
freshly-booted machine, or when Finale has been newly opened. The first 
time the bug occurred Finale crashed soon afterwards, and I have always 
quit and restarted Finale immediately after noticing the bug every time 
since.

Christopher
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[A-NO-NE Music]

Christopher Smith / 05.1.23 / 02:33 AM wrote:

>I did not know that. You were right on to point that out to me. I ran 
>Terminal for the first time when Karen mentioned it a few posts ago.

There are a few useful tools:
MemoryStick:

This will show you the number of swapfile and active/inactive memory, and
warn you when paging.

MenuMeters

It gives much more detailed status in many areas.  But you need to be
careful of polling since, as top also does, polling eats CPU.

And my favorite: GeekTools, which I can't live without.

I use this tool to monitor system.log and console.log on my desktop.  I
also run shell command 'vm_stat' to monitor my vm status which is
displayed on my desktop as well.  This tool is essential to recording
session work I do since it gives me early warning in case of trouble.

-- 

- Hiro

Hiroaki Honshuku, A-NO-NE Music, Boston, MA
 


___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Christopher Smith]

On Jan 21, 2005, at 1:39 AM, A-NO-NE Music wrote:
You might want to consider rebooting OSX time to time because the 
number
of swapfile will not go away less than 4 or 5 until you reboot.  OSX
needs about 1GB free space for vm stack, which can be eaten up quickly
when swapfile() accumulates 6-7 of them, and Safari can do that as well
as Photoshop.  Oh, iPhoto is probably the worst.

Thank you, that is very informative. I will definitely keep that in 
mind.


Also, forgive me if you already know this, when you are running 'top',
you need to ignore inactive portion.  They are addressed alright, but
they are not occupied.
I did not know that. You were right on to point that out to me. I ran 
Terminal for the first time when Karen mentioned it a few posts ago.

Christopher
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Christopher Smith]

On Jan 20, 2005, at 7:47 PM, [EMAIL PROTECTED] wrote:
On my machine, I got to the paging stage with no other files open 
(pictures, PDF's etc.) in the other applicationsjust files open in 
Finale.  Add PDF's pics etc in and I'll bet you are getting low on 
free memory.  Additionally, if there is a memory leak anywhere (up 
until 10.3.5 at least, Safari was rumored to have this problem) then 
your free RAM would be drifting down further over time until there is 
a restart.

Safari leaks memory? I'm not exactly a computer geek, so I don't know 
what this means. Does it mean that RAM it was supposed to have 
earmarked for its own use gets written by other apps? I have noticed 
that Safari is the only app in OS X that crashes more or less 
regularly. Are you saying that if I get in the habit of quitting Safari 
when I am done, instead of just closing windows, that I might get 
around the paging thing? or maybe reduce the occurrence of the Finale 
bug?

Christopher
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[A-NO-NE Music]

David W. Fenton / 05.1.22 / 07:37 PM wrote:

>Mac users are probably confused about virtual memory because of the 
>way it was bolted onto Mac OS as an extension that often conflicted 
>with applications.
>
>You're now living in a completely different world, one where the apps 
>don't know anything about managing system memory at all. They only 
>know about their own memory requirements.
>
>Keep in mind that under OS X you don't have to set the amount of 
>memory to be allocated to an application (as was the case with Mac 
>OS). This is a direct indication of the fact that memory management 
>is now wholly owned by the operating system itself.


I don't think you understood me.  You seems to think I was talking about
Classic Mac OSes, while you are clearly based on NT Kernel.  Did you know
OSX blocks swapfile allocation in 67.1MB each for first two, then size
multiplies after, i.e., the 3rd is about 135MB, and the 4th is about
268MB, and so on.?  It's not like NT Kernel does at all.  And, as I said
before, there are some apps that calls vm at launch, and the vm size
never changes after that regardless of the presence of available physical
memory and the size of the project file.

And to your other post, as far as I know, OSX did not take vm
architecture from BSD kernel, which was the base design of Darwin Kernel.

Oh, and when OSX runs out of physical memory and vm space, it will warn
you that you need to exit open applications to free up the memory space,
but it will continue to run with, as you said, slow performance if one
ignores the warning :-)


-- 

- Hiro

Hiroaki Honshuku, A-NO-NE Music, Boston, MA
 


___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[laloba2]

On 21 Jan 2005 at 18:14, [EMAIL PROTECTED] wrote:
 >On 21 Jan 2005 at 15:43, [EMAIL PROTECTED] wrote:
 >
 >>  >[EMAIL PROTECTED] / 05.1.21 / 00:52 PM wrote:
 >
 >[]
 >
 >>  But I think that if the problem was solely due to an address bug,
 >>  it would happen more often.  And problems with addressing is
 >>  exactly what can happen during a page fault...(when the working
 >>  set of pages of a process, which contains addressing information
 >>  doesn't have enough physical memory...a page fault occursit
 >>  the OS has enough memory to keep the working sets of all processes
 >>  in physical memory there will be fewer page faults.)  Page faults
 >>  don't occur very often.  Only when the system is stressed do they
 >>  happen more frequently...the same goes for the Overwrite Bug.
 >
 >A page fault in a working virtual memory subsystem will *never*
 >result in the memory tables being corrupted so that pages get mixed
 >up.
 But I'm not talking about a working virtual memory subsystem...I'm
 talking about a stressed one...
No, a stressed VM is not a non-working one.
A stressed VM will be slow. It will cause everything to drag to a
crawl.
But it will *never* corrupt data.
If it does, it's not a working VM subsystem!
O.K...I'm with you...I understand.  There may have been a 
misunderstanding here...when I suggested that data may be getting 
corrupted...  I may not have been able to clearly articulate that I 
never meant the OS and it's VM subsystem was doing the 
corrupting...just that something was going haywire with Finale at 
this point. Not by any fault of the OS but rather because of the 
state the OS was in...yes still working the way it was supposed to 
and the way it was designed to.  But sluggish and/or thrashing.



 . . . a working car still won't run if there
 isn't enough gas in itand it will sputter on fumes.  I understand
 what you are saying here...but even if the system is a well designed
 one..which it is, if resources aren't there,  it won't work correctly.
Yes, it *will* work correctly.
That is defined as:
1. swaps pages in and out as needed, however slowly, and even if it
results in thrashing and completely halts for the applications being
served by the VM subsystem.
2. maintains 100% data integrity of all the data pages being managed.
No matter how much stress you place on a VM subsystem, it will
perform these functions.
O.KI understand what you are saying...and I'm still with you. :-)
Now, that doesn't mean the applications being served by it will be
usable at all, but that's a completely different set of issues.
And *that's* the set of issues you're defining as "not working
correctly." It's an end user's point of view, not a data point of
view.
Yes, very well put...probably better than I was able to put it but 
this is what I'm getting at.  Thank you!

My theory is that at this point, there is a problem with the way 
Finale has been programmed.  A problem, which results in the 
Overwrite Bug, that when there is more memory in a machine, doesn't 
occur.  But when there isn't enough memory and the system gets to the 
point of thrashing, then the mistakes made in the way that Finale was 
written result in this problem.

Can you think of anything in the way a program is coded that would 
fit into this scenario and possibly cause the overwrite bug? 
Problems with the way the program uses threads?  I/O issues? 
Caching?  etc?

I'm doing my best to guess at causes because I always have a desire 
to get an explanation that works for a given problem.  But you have a 
good understanding of what is going on under the hood and you are 
also very good at articulating these things.  So if you have any 
ideas, I'd love to hear about them!!  :-)


In short, I can state with about 99.9% certainty that the OS X
virtual memory manager is *not* causing corruption of Finale's data.
Again, agreed.

 I've read in the past about preferences being affected by these sorts
 > of circumstances.  So could it be that other data can also be affected
 or even the way that data is being accessed is being affected?  Also,
 while the OS is UNIX based, it is quite different in many ways.  Many
 of the differences lie in the way memory is dealt with.  Which also
 makes me wonder if MM is using Unix programmers to make the transition
 or if they have hired people that are OS X programmers.
I don't know why preferences would affect virtual memory, unless they
are settings that you can use to tweak VM settings.
Not the preferences affecting virtual memory, but depending on the 
way an application is programmed as to when and how it accesses it's 
preferences...if there has been a system slowdown due to a RAM 
shortage, the preferences will appear to have not been saved or will 
revert to dafault either partially or fully.

As to Unix, I'm not sure if Apple wrote its own VM for OS X or if the
VM OS X uses is adapted from the Unix variant. Given that it's
definitely something that is intimately tied up with t

Re: [Finale] File Overwrite Bug in Action

[David W. Fenton]

On 22 Jan 2005 at 16:18, Jari Williamsson wrote:

> David W. Fenton wrote:
> 
> > But it *has* happened to *me* on Windows -- I've never lost data,
> > but as I've said many times, I've seen the wrong data displayed for
> > the window titles (i.e., document names).
> 
> And I also saw this occasionally in FinWin2003, but I believe it was
> fixed in FinWin2004. Or are you saying you have seen this in Fin2004
> or Fin2005? I haven't seen a single report about this from a
> FinWin2005 user but numerous reports from FinMac2005 users.

I saw it in WinFin97 and WinFin2K3, which is the latest version I 
have (and may be the last I ever own).

-- 
David W. Fentonhttp://www.bway.net/~dfenton
David Fenton Associateshttp://www.bway.net/~dfassoc

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[David W. Fenton]

On 22 Jan 2005 at 9:13, Darcy James Argue wrote:

> > Darcy James Argue wrote:
> >
> >> I have no idea if that's a workable solution, but I would like Coda
> >> to at least *try* it.  Since the problem with the corrupted
> >> pointers is proving elusive, maybe it's time to address the root of
> >> the problem -- shared temp files.  If the same temp files weren't
> >> shared by multiple documents, then the file overwrite bug would
> >> never occur. 
> >>  (Or at least, that's what Jari seems to be saying.)
> >
> > I have never, ever AFAIK said that the overwrite problem has
> > anything to do with temp files!
> 
> Okay, then I'm misunderstanding what you are saying.  Some people have
> suggested that the file overwrite bug occurs because Finale does not
> segregate its temp files -- all open documents share the same set of
> temp files.  This is instead of each open document having it's own,
> exclusive set of temp files.  So the idea is that the file overwrite
> but is caused when the temp files become corrupted and start pointing
> to the wrong documents.

Actually, I would say that the temp files don't need to be corrupted, 
just the pointer table.

> If you don't believe this is a plausible explanation, then what *do*
> you think is going on?

Well, since the problem is a mismatch between data and document 
window, it's theoretically possible for the problem to exist without 
shared temp files.

I just think that it's *more* likely to happen if temp files are 
shared, since the mapping is more complicated -- it's not just a 
mapping of a document window to a file name, but of a document window 
to an offset within a file (or more probably to an offset within a 
lookup table in the header of a file). Somewhere along the line, data 
is getting moved to an unexpected location and the pointers aren't 
getting updated to reflect the new location (alternative, the data is 
staying in the same place and for some reason the pointers are being 
altered to point to something else).

It could also be that the mapping problem is between the document 
windows and certain Finale memory structures, and that this is where 
the mapping is getting screwed up.

So, Jari's right -- it certainly could have nothing to do with the 
temp files.

But I still think mixing data from multiple files in temp files is 
asking for just this kind of trouple.

-- 
David W. Fentonhttp://www.bway.net/~dfenton
David Fenton Associateshttp://www.bway.net/~dfassoc

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[David W. Fenton]

On 21 Jan 2005 at 23:00, A-NO-NE Music wrote:

> David W. Fenton / 05.1.21 / 06:10 PM wrote:
> >The programmers of OS X, you mean -- Finale knows nothing about
> >virtual memory, which is entirely handled by the operating system's
> >virtual memory subsystem.
> 
> Well, Finale might or might not, we won't know. . . .

Yes, we *do* know.

Modern operating systems have virtual memory subsystems built in at 
the lowest level of the OS.

> . . . Some apps does set vm
> amount on launch.  Most of the DSP application does that.  But you
> might be right.  Finale doesn't require real-time disk I/O so
> pre-caching might not be happening.

Mac users are probably confused about virtual memory because of the 
way it was bolted onto Mac OS as an extension that often conflicted 
with applications.

You're now living in a completely different world, one where the apps 
don't know anything about managing system memory at all. They only 
know about their own memory requirements.

Keep in mind that under OS X you don't have to set the amount of 
memory to be allocated to an application (as was the case with Mac 
OS). This is a direct indication of the fact that memory management 
is now wholly owned by the operating system itself.

-- 
David W. Fentonhttp://www.bway.net/~dfenton
David Fenton Associateshttp://www.bway.net/~dfassoc

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[David W. Fenton]

On 21 Jan 2005 at 18:14, [EMAIL PROTECTED] wrote:

> >On 21 Jan 2005 at 15:43, [EMAIL PROTECTED] wrote:
> >
> >>  >[EMAIL PROTECTED] / 05.1.21 / 00:52 PM wrote:
> >
> >[]
> >
> >>  But I think that if the problem was solely due to an address bug,
> >>  it would happen more often.  And problems with addressing is
> >>  exactly what can happen during a page fault...(when the working
> >>  set of pages of a process, which contains addressing information
> >>  doesn't have enough physical memory...a page fault occursit
> >>  the OS has enough memory to keep the working sets of all processes
> >>  in physical memory there will be fewer page faults.)  Page faults
> >>  don't occur very often.  Only when the system is stressed do they
> >>  happen more frequently...the same goes for the Overwrite Bug.
> >
> >A page fault in a working virtual memory subsystem will *never*
> >result in the memory tables being corrupted so that pages get mixed
> >up.
> 
> But I'm not talking about a working virtual memory subsystem...I'm
> talking about a stressed one...

No, a stressed VM is not a non-working one.

A stressed VM will be slow. It will cause everything to drag to a 
crawl.

But it will *never* corrupt data.

If it does, it's not a working VM subsystem!

> . . . a working car still won't run if there
> isn't enough gas in itand it will sputter on fumes.  I understand
> what you are saying here...but even if the system is a well designed
> one..which it is, if resources aren't there,  it won't work correctly.

Yes, it *will* work correctly.

That is defined as:

1. swaps pages in and out as needed, however slowly, and even if it 
results in thrashing and completely halts for the applications being 
served by the VM subsystem.

2. maintains 100% data integrity of all the data pages being managed.

No matter how much stress you place on a VM subsystem, it will 
perform these functions.

Now, that doesn't mean the applications being served by it will be 
usable at all, but that's a completely different set of issues.

And *that's* the set of issues you're defining as "not working 
correctly." It's an end user's point of view, not a data point of 
view.

In short, I can state with about 99.9% certainty that the OS X 
virtual memory manager is *not* causing corruption of Finale's data.

> So if you would, please humor me for a minute.  It appears that you
> know a great deal about this and can shed some light on the problem
> which would be helpful. . . 

I know a bit about the architecture of operating systems and how 
virtual memory works. I know nothing specific about OS X, except that 
it's built by a reputable company that really knows what it's doing 
and that it is based on a modern OS kernel, one that has incorporated 
virtual memory management for a long time.

> . . . What happens in OS X when there aren't enough
> resources to keep all the necessary working sets up and running in
> Physical RAM which is where they need to be? . . .

As you said, a page fault, which is a form of software interrupt 
which causes everything in the application space to stop while the VM 
re-arranges memory to try to give the applications currently 
requesting new memory pages the resources they need. When it's 
completed its job, it allows the applications to continue executing, 
in exactly the same place where it had earlier halted them.

> . . . It just doesn't make
> sense that it would be business as usual, there would have to be some
> fallout from all of this? . . .

Page faults due to lack of memory happen *all the time* during the 
regular operation of every modern operating system. It's only when 
things are at borderline conditions that the user even notices 
anything other than, perhaps, a momentary pause (and the sound of the 
hard drive churning).

This is because application execution is *halted* while memory is 
reconfigured.

> . . . And the system doesn't always just quit. . . .

It should *never* quit -- that's the whole point of a virtual memory 
system, which is designed to make it possible to operate as though 
you have more memory than is physically present for the OS.

> I've read in the past about preferences being affected by these sorts
> of circumstances.  So could it be that other data can also be affected
> or even the way that data is being accessed is being affected?  Also,
> while the OS is UNIX based, it is quite different in many ways.  Many
> of the differences lie in the way memory is dealt with.  Which also
> makes me wonder if MM is using Unix programmers to make the transition
> or if they have hired people that are OS X programmers.

I don't know why preferences would affect virtual memory, unless they 
are settings that you can use to tweak VM settings.

As to Unix, I'm not sure if Apple wrote its own VM for OS X or if the 
VM OS X uses is adapted from the Unix variant. Given that it's 
definitely something that is intimately tied up with the basic kernel-
level operation of the OS

Re: [Finale] File Overwrite Bug in Action

[Jari Williamsson]

David W. Fenton wrote:
But it *has* happened to *me* on Windows -- I've never lost data, but 
as I've said many times, I've seen the wrong data displayed for the 
window titles (i.e., document names).
And I also saw this occasionally in FinWin2003, but I believe it was 
fixed in FinWin2004. Or are you saying you have seen this in Fin2004 or 
Fin2005?
I haven't seen a single report about this from a FinWin2005 user but 
numerous reports from FinMac2005 users.

Best regards,
Jari Williamsson
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Darcy James Argue]

- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY
On 22 Jan 2005, at 9:13 AM, Darcy James Argue wrote:
Darcy James Argue wrote:
I have no idea if that's a workable solution, but I would like Coda 
to at least *try* it.  Since the problem with the corrupted pointers 
is proving elusive, maybe it's time to address the root of the 
problem -- shared temp files.  If the same temp files weren't shared 
by multiple documents, then the file overwrite bug would never 
occur.  (Or at least, that's what Jari seems to be saying.)
I have never, ever AFAIK said that the overwrite problem has anything 
to do with temp files!
Okay, then I'm misunderstanding what you are saying.  Some people have 
suggested that the file overwrite bug occurs because Finale does not 
segregate its temp files -- all open documents share the same set of 
temp files.  This is instead of each open document having it's own, 
exclusive set of temp files.  So the idea is that the file overwrite 
but is caused when the temp files become corrupted and start pointing 
to the wrong documents.

If you don't believe this is a plausible explanation, then what *do* 
you think is going on?

- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Darcy James Argue]

On 22 Jan 2005, at 7:07 AM, Jari Williamsson wrote:
Darcy James Argue wrote:
(Of course, they could also just fix the problem where the window 
handle/ID starts to map to the wrong Enigma Doc ID, but apparently 
that's easier said than done.)
But that's _exactly_ what they have to do!!!
Moving the Enigma mapping currently made to disc into RAM will not 
solve _anything_ if the window is already mapping to the wrong Enigma 
database.
I realize that.  But what I was *suggesting* was having separate temp 
files for each document, instead of the current system of shared temp 
files.

But now you're saying that you don't think temp files have anything to 
do with the problem.  So where *is* the window handle/ID - Enigma Doc 
ID information stored?

Perhaps it would be more productive if the Mac users who repeatedly 
experience this problem analyzed (in detail) what they did _prior_ to 
when the problem occured that is _different_ to what they do when it 
does _not_ happen. It can be any silly little thing along the way that 
matters here.
We have been trying to do just that, but, like the Text Block bug, it's 
proving to be extremely tricky to reproduce.  Chris Smith and I have 
already written Coda multiple times with detailed descriptions of 
exactly what we were doing when it struck.  (Although again, because of 
the nature of the bug, it's almost impossible to know *exactly* when it 
struck.)

- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Darcy James Argue]

Darcy James Argue wrote:
I have no idea if that's a workable solution, but I would like Coda 
to at least *try* it.  Since the problem with the corrupted pointers 
is proving elusive, maybe it's time to address the root of the 
problem -- shared temp files.  If the same temp files weren't shared 
by multiple documents, then the file overwrite bug would never occur. 
 (Or at least, that's what Jari seems to be saying.)
I have never, ever AFAIK said that the overwrite problem has anything 
to do with temp files!
Okay, then I'm misunderstanding what you are saying.  Some people have 
suggested that the file overwrite bug occurs because Finale does not 
segregate its temp files -- all open documents share the same set of 
temp files.  This is instead of each open document having it's own, 
exclusive set of temp files.  So the idea is that the file overwrite 
but is caused when the temp files become corrupted and start pointing 
to the wrong documents.

If you don't believe this is a plausible explanation, then what *do* 
you think is going on?

- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Jari Williamsson]

Darcy James Argue wrote:
(Of course, they could also just fix the problem where the window 
handle/ID starts to map to the wrong Enigma Doc ID, but apparently 
that's easier said than done.)
But that's _exactly_ what they have to do!!!
Moving the Enigma mapping currently made to disc into RAM will not solve 
_anything_ if the window is already mapping to the wrong Enigma database.

Perhaps it would be more productive if the Mac users who repeatedly 
experience this problem analyzed (in detail) what they did _prior_ to 
when the problem occured that is _different_ to what they do when it 
does _not_ happen. It can be any silly little thing along the way that 
matters here.

Best regards,
Jari Williamsson
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Jari Williamsson]

Darcy James Argue wrote:
I have no idea if that's a workable solution, but I would like Coda to 
at least *try* it.  Since the problem with the corrupted pointers is 
proving elusive, maybe it's time to address the root of the problem -- 
shared temp files.  If the same temp files weren't shared by multiple 
documents, then the file overwrite bug would never occur.  (Or at least, 
that's what Jari seems to be saying.)
I have never, ever AFAIK said that the overwrite problem has anything to 
do with temp files! And actually I have a hard time believing that it 
should be part of the overwrite problem.

Best regards,
Jari Williamsson
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[laloba2]

On 21 Jan 2005 at 15:43, [EMAIL PROTECTED] wrote:
 >[EMAIL PROTECTED] / 05.1.21 / 00:52 PM wrote:
[]
 But I think that if the problem was solely due to an address bug, it
 would happen more often.  And problems with addressing is exactly what
 can happen during a page fault...(when the working set of pages of a
 process, which contains addressing information doesn't have enough
 physical memory...a page fault occursit the OS has enough memory
 to keep the working sets of all processes in physical memory there
 will be fewer page faults.)  Page faults don't occur very often.  Only
 when the system is stressed do they happen more frequently...the same
 goes for the Overwrite Bug.
A page fault in a working virtual memory subsystem will *never*
result in the memory tables being corrupted so that pages get mixed
up.
But I'm not talking about a working virtual memory subsystem...I'm 
talking about a stressed one...a working car still won't run if there 
isn't enough gas in itand it will sputter on fumes.  I understand 
what you are saying here...but even if the system is a well designed 
one..which it is, if resources aren't there,  it won't work correctly.

So if you would, please humor me for a minute.  It appears that you 
know a great deal about this and can shed some light on the problem 
which would be helpful.  What happens in OS X when there aren't 
enough resources to keep all the necessary working sets up and 
running in Physical RAM which is where they need to be?  It just 
doesn't make sense that it would be business as usual, there would 
have to be some fallout from all of this?  And the system doesn't 
always just quit.  I've read in the past about preferences being 
affected by these sorts of circumstances.  So could it be that other 
data can also be affected or even the way that data is being accessed 
is being affected?  Also, while the OS is UNIX based, it is quite 
different in many ways.  Many of the differences lie in the way 
memory is dealt with.  Which also makes me wonder if MM is using Unix 
programmers to make the transition or if they have hired people that 
are OS X programmers.

I'd like to hear what you think about this :-)
TIA,
-K
P.S...
Again, let me repeat that I've seen a mismatch between document
window and content on Windows, so it probably has *nothing* to do
fundamentally with OS X,
But what you are describing here is a bit different from what is 
going on with the Overwrite Bug on a Mac. :-)

--
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[laloba2]

On 21 Jan 2005 at 18:39, Darcy James Argue wrote:
 > I think the people who are blaming memory paging for the corruption
 > have a fundamental misunderstanding of the structure of a modern
 > operating system.
 Just to be clear -- I'm not "blaming memory paging for the corruption"
 and I don't think anyone else here is either.
Not you, Darcy, but others have suggesting paging as a possible
source of corruption, which is blatantly impossible, unless the OS X
virtual memory system was improperly designed.
Just for the record...I'm not attributing the problem to paging either :-)
--
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[David W. Fenton]

On 21 Jan 2005 at 20:02, Darcy James Argue wrote:

> Okay, I see what you are saying now -- I assumed that OS X was 
> accurately reporting the size of Fin temp files, whereas Windows was
> just giving you zero KB for the whole temp files folder. . . .

I'm just reporting how other database applications utilize temp 
files. If the amount of space needed were really so trivial, why 
would something so slow as disk space be used for it?

> . . . But what you
> say makes sense.  I would like some confirmation from Coda about this,
> though.  Seriously, I wouldn't be surprised if the temp files were
> small enough to be stored in RAM, and the whole "temp file" system was
> just an inefficient holdover from Finale's earlier incarnations.  (I
> mean, think of all the other aspects of Finale that meet that
> description!)

If I'm not mistaken, Finale back in the 2.x days did not use temp 
files. And those were the days in which 15MBs was a lot of RAM.

But maybe I just didn't notice it, or just don't remember.

> >> (1) Segregate the temp files so that they are not shared between
> >> multiple documents.
> >
> > I've never quite understood the logic of the explanation we were
> > long ago given for the combined temp files, as it's an optimization
> > for something I never do (I just never copy data between files, or
> > maybe once every 6 months).
> 
> I do it a little more frequently, but it's certainly not something I
> do every day.  And I would *much* prefer waiting a little longer when
> copying between files to the current situation of taking a massive
> gamble every time I want to have multiple simultaneous files open --
> which *is* something I do every day.  (In fact, it astounds me that so
> many people on this list never have multiple documents open
> simultaneously.)

I don't very often at all. The only time I tend to is when extracting 
parts, which is itself not something I do very often, and even then, 
it's not a state that I end up staying in for a long period of time.

> > No, it's because you now have good disk caching, so that the temp
> > files are in RAM already (in the disk cache).
> 
> Ah.  I see now.  I guess that hadn't occurred to me -- probably
> because Finale performance in Mac OS X is already so poor, I found it
> difficult to entertain the idea that things could be any *worse*.

The performance problems are no doubt optimizable. I would expect the 
next OS X version of Finale to be much faster.

This stuff is hard.

Transitioning to a completely different platform is tough work 
because the tricks you know either don't work or make things worse in 
the new environment. It's quite common for a first major version to 
be a performance hog, and it's a proper programming strategy to leave 
performance optimization to a secondary release.

-- 
David W. Fentonhttp://www.bway.net/~dfenton
David Fenton Associateshttp://www.bway.net/~dfassoc

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Darcy James Argue]

Hi David,
Okay, I see what you are saying now -- I assumed that OS X was 
accurately reporting the size of Fin temp files, whereas Windows was 
just giving you zero KB for the whole temp files folder.  But what you 
say makes sense.  I would like some confirmation from Coda about this, 
though.  Seriously, I wouldn't be surprised if the temp files were 
small enough to be stored in RAM, and the whole "temp file" system was 
just an inefficient holdover from Finale's earlier incarnations.  (I 
mean, think of all the other aspects of Finale that meet that 
description!)

(1) Segregate the temp files so that they are not shared between
multiple documents.
I've never quite understood the logic of the explanation we were long
ago given for the combined temp files, as it's an optimization for
something I never do (I just never copy data between files, or maybe
once every 6 months).
I do it a little more frequently, but it's certainly not something I do 
every day.  And I would *much* prefer waiting a little longer when 
copying between files to the current situation of taking a massive 
gamble every time I want to have multiple simultaneous files open -- 
which *is* something I do every day.  (In fact, it astounds me that so 
many people on this list never have multiple documents open 
simultaneously.)

No, it's because you now have good disk caching, so that the temp
files are in RAM already (in the disk cache).
Ah.  I see now.  I guess that hadn't occurred to me -- probably because 
Finale performance in Mac OS X is already so poor, I found it difficult 
to entertain the idea that things could be any *worse*.

Cheers,
- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY
On 21 Jan 2005, at 7:45 PM, David W. Fenton wrote:
On 21 Jan 2005 at 19:32, Darcy James Argue wrote:
Brooklyn, NYOn 21 Jan 2005, at 7:10 PM, David W. Fenton wrote:
I don't know what the actual filespace usage of Finale temp files on
disk
Mine are typically 11-15 MB total, which is practically nothing.  It
seems silly to write files that small to disk, instead of to RAM.
That's about what Windows reports, too, but, as I explained, what
your shell reports may or may not indicate exactly how much file
space is actually being used. Your shell may report the size of a
file as 0 bytes when it's actually taking up hundreds of MBs (if it's
in the process of being written to in a single operation, the file
size won't be updated until the whole write operation is complete).
So, as I said, we don't really know what the actual filespace usage
of Finale's temp files really is.
So, my assumption is that Finale is solving the same kinds of
problems in temp files instead of in RAM precisely because the space
needed is quite huge, too large for standard RAM configurations.
The space needed is trivial -- like I said, 11-15 MB.  Temp files in
Finale are simply a legacy from the days when 15 MB of RAM *was* a big
deal.  That's the only reason these are temp files and not written to
RAM by default.
You're relying on information that is not necessarily accurate.
When Jet is writing its 100MB files, the file system doesn't reflect
that until the file is finished writing, and in most cases, the file
is immediately deleted after it's been used. That means, unless
you're looking at the exact second the file is written to and in the
instant before it's deleted, you'll never see the *actual* disk space
being used.
So, you really don't *know* whether the amount of space the temp
files are using is trivial or not.
(Of course, they could also just fix the problem where the window
handle/ID starts to map to the wrong Enigma Doc ID, but apparently
that's easier said than done.)
Storing temp files in RAM (which is really not using temp files at
all, of course) would do *nothing* to fix the problem if the problem
is messed up pointers.
No, but segregating temp files for each document -- instead of having
the same temp file map to all open documents -- *would* solve the
problem. . . .
True, but it has zilch to do with where the temporary data is stored
(on disk or in RAM).
. . . *That's* what I'm advocating -- or at least, that's a
possibility I would like Coda to investigate.  Their stated reason for
not doing so is that it would make inter-document copying slower.  I'm
suggesting they try using segregated temp files for each document, but
store them in RAM to make them faster.  Maybe then the speed would
remain about the same, and we wouldn't have the corruption problems
we're having now.
And I'm suggesting that the kind of database operations that the temp
files are being used for actually take up orders of magnitude more
disk space than you ever know about, and that this is why the files
are *not* stored in RAM already.
I'm perfectly aware that storing temp files in RAM *alone* would do
nothing to fix the problem.  But I'm suggesting a (possible)
two-pronged solution:
(1) Segregate the temp files so that they are not shared between
multiple documents.
I've never quite understood the 

Re: [Finale] File Overwrite Bug in Action

[David W. Fenton]

On 21 Jan 2005 at 19:32, Darcy James Argue wrote:

> Brooklyn, NYOn 21 Jan 2005, at 7:10 PM, David W. Fenton wrote:
> 
> > I don't know what the actual filespace usage of Finale temp files on
> > disk
> 
> Mine are typically 11-15 MB total, which is practically nothing.  It
> seems silly to write files that small to disk, instead of to RAM.

That's about what Windows reports, too, but, as I explained, what 
your shell reports may or may not indicate exactly how much file 
space is actually being used. Your shell may report the size of a 
file as 0 bytes when it's actually taking up hundreds of MBs (if it's 
in the process of being written to in a single operation, the file 
size won't be updated until the whole write operation is complete).

So, as I said, we don't really know what the actual filespace usage 
of Finale's temp files really is.

> > So, my assumption is that Finale is solving the same kinds of
> > problems in temp files instead of in RAM precisely because the space
> > needed is quite huge, too large for standard RAM configurations.
> 
> The space needed is trivial -- like I said, 11-15 MB.  Temp files in
> Finale are simply a legacy from the days when 15 MB of RAM *was* a big
> deal.  That's the only reason these are temp files and not written to
> RAM by default.

You're relying on information that is not necessarily accurate.

When Jet is writing its 100MB files, the file system doesn't reflect 
that until the file is finished writing, and in most cases, the file 
is immediately deleted after it's been used. That means, unless 
you're looking at the exact second the file is written to and in the 
instant before it's deleted, you'll never see the *actual* disk space 
being used.

So, you really don't *know* whether the amount of space the temp 
files are using is trivial or not.

> >> (Of course, they could also just fix the problem where the window
> >> handle/ID starts to map to the wrong Enigma Doc ID, but apparently
> >> that's easier said than done.)
> >
> > Storing temp files in RAM (which is really not using temp files at
> > all, of course) would do *nothing* to fix the problem if the problem
> > is messed up pointers.
> 
> No, but segregating temp files for each document -- instead of having
> the same temp file map to all open documents -- *would* solve the
> problem. . . .

True, but it has zilch to do with where the temporary data is stored 
(on disk or in RAM).

> . . . *That's* what I'm advocating -- or at least, that's a
> possibility I would like Coda to investigate.  Their stated reason for
> not doing so is that it would make inter-document copying slower.  I'm
> suggesting they try using segregated temp files for each document, but
> store them in RAM to make them faster.  Maybe then the speed would
> remain about the same, and we wouldn't have the corruption problems
> we're having now.

And I'm suggesting that the kind of database operations that the temp 
files are being used for actually take up orders of magnitude more 
disk space than you ever know about, and that this is why the files 
are *not* stored in RAM already.

> I'm perfectly aware that storing temp files in RAM *alone* would do
> nothing to fix the problem.  But I'm suggesting a (possible)
> two-pronged solution:
> 
> (1) Segregate the temp files so that they are not shared between
> multiple documents.

I've never quite understood the logic of the explanation we were long 
ago given for the combined temp files, as it's an optimization for 
something I never do (I just never copy data between files, or maybe 
once every 6 months).

> (2) Store the temp files in RAM to alleviate the performance issues
> caused by (1).

My bet is that this would cause more performance problems than it 
would solve because if temp files truly were so tiny, why in the 
world wouldn't those temporary operations be done in RAM already? It 
makes no sense to rely on the file system for working with data 
structures that would easily fit in RAM.

So, I can only conclude that these temp files are just stumps (the 
smallest size the files ever get) and that when actually being 
actively used balloon to much larger size and then shrink back to the 
stump size as soon as whatever process they were being used for is 
complete.

> I have no idea if that's a workable solution, but I would like Coda to
> at least *try* it.  Since the problem with the corrupted pointers is
> proving elusive, maybe it's time to address the root of the problem --
> shared temp files.  If the same temp files weren't shared by multiple
> documents, then the file overwrite bug would never occur.  (Or at
> least, that's what Jari seems to be saying.)

I would agree on the shared temp files.

I disagree on moving temp files to RAM -- no programmer would write 
to disk data that can easily be processed in RAM, so I can only 
conclude that the amount of data being processed in the temp files is 
actually much larger than is ever reported by the shells we are usin

Re: [Finale] File Overwrite Bug in Action

[Darcy James Argue]

Brooklyn, NYOn 21 Jan 2005, at 7:10 PM, David W. Fenton wrote:
I don't know what the actual filespace usage of Finale temp files on
disk
Mine are typically 11-15 MB total, which is practically nothing.  It 
seems silly to write files that small to disk, instead of to RAM.

So, my assumption is that Finale is solving the same kinds of
problems in temp files instead of in RAM precisely because the space
needed is quite huge, too large for standard RAM configurations.
The space needed is trivial -- like I said, 11-15 MB.  Temp files in 
Finale are simply a legacy from the days when 15 MB of RAM *was* a big 
deal.  That's the only reason these are temp files and not written to 
RAM by default.

(Of course, they could also just fix the problem where the window
handle/ID starts to map to the wrong Enigma Doc ID, but apparently
that's easier said than done.)
Storing temp files in RAM (which is really not using temp files at
all, of course) would do *nothing* to fix the problem if the problem
is messed up pointers.
No, but segregating temp files for each document -- instead of having 
the same temp file map to all open documents -- *would* solve the 
problem.  *That's* what I'm advocating -- or at least, that's a 
possibility I would like Coda to investigate.  Their stated reason for 
not doing so is that it would make inter-document copying slower.  I'm 
suggesting they try using segregated temp files for each document, but 
store them in RAM to make them faster.  Maybe then the speed would 
remain about the same, and we wouldn't have the corruption problems 
we're having now.

I'm perfectly aware that storing temp files in RAM *alone* would do 
nothing to fix the problem.  But I'm suggesting a (possible) 
two-pronged solution:

(1) Segregate the temp files so that they are not shared between 
multiple documents.

(2) Store the temp files in RAM to alleviate the performance issues 
caused by (1).

I have no idea if that's a workable solution, but I would like Coda to 
at least *try* it.  Since the problem with the corrupted pointers is 
proving elusive, maybe it's time to address the root of the problem -- 
shared temp files.  If the same temp files weren't shared by multiple 
documents, then the file overwrite bug would never occur.  (Or at 
least, that's what Jari seems to be saying.)

 If all you're doing is changing whether the
pointers point to files or pages in RAM, you're not actually
addressing the fundamental problem at all.
You may get a performance increase.
You may not.
Back in OS 9, we got a *dramatic* performance increase by storing temp 
files on RAM disks.

This doesn't happen with the RAM disks available to us in OS X -- I 
suspect because of poor implementation.  (Also, I don't even know of a 
RAM disk that works with 10.3.  Most only support 10.2 and lower.)

- Darcy
-
[EMAIL PROTECTED]
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[David W. Fenton]

On 21 Jan 2005 at 19:13, Raymond Horton wrote:

> In FINWIN 2005a, I have often extracted a part from a score, then
> edited the part.  Then when I come back to the score, I temporarily
> see the part where the score should be until I do a screen redraw. 
> 
> This is as close as I have ever gotten to this bug. 
> 
> Is this, by any chance, what you mean by "seen the wrong data
> displayed for the window titles?"

Nope. In the cases where I experienced it, a screen redraw didn't 
change the data displayed -- it was still wrong.

Also, in some cases, closing documents one by one eventually led to a 
final single document that could not be closed without closing Finale 
itself, which means that in addition to messed up pointers, there was 
some fundamental problem with the basic MDI structure itself.

-- 
David W. Fentonhttp://www.bway.net/~dfenton
David Fenton Associateshttp://www.bway.net/~dfassoc

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[David W. Fenton]

On 21 Jan 2005 at 15:43, [EMAIL PROTECTED] wrote:

> >[EMAIL PROTECTED] / 05.1.21 / 00:52 PM wrote:

[]

> But I think that if the problem was solely due to an address bug, it
> would happen more often.  And problems with addressing is exactly what
> can happen during a page fault...(when the working set of pages of a
> process, which contains addressing information doesn't have enough
> physical memory...a page fault occursit the OS has enough memory
> to keep the working sets of all processes in physical memory there
> will be fewer page faults.)  Page faults don't occur very often.  Only
> when the system is stressed do they happen more frequently...the same
> goes for the Overwrite Bug.

A page fault in a working virtual memory subsystem will *never* 
result in the memory tables being corrupted so that pages get mixed 
up.

Furthermore, memory pages are not necessarily the same size as the 
units used in the actual files represented by those pages in memory. 
This means that a swap file page may have data from multiple memory 
pages. Why does that matter? Well, for the kind of corruption being 
experienced to be due to corrupted memory tables, the correspondence 
between memory structure (swapped page) and file structure 
(documents) would have to be one-to-one, since the corruption is one-
to-one (the contents of one entire document replaces the contents of 
another entire document).

> >...related to hacked and twisted code to make Finale work under
> >OSX.
> 
> I whole heartedly agree that something has not been coded properly
> under OSX and that that is adding to the problem.  :-)

Again, let me repeat that I've seen a mismatch between document 
window and content on Windows, so it probably has *nothing* to do 
fundamentally with OS X, though the conversion of Finale to run on OS 
X seems to have made the problem much more severe for Finale running 
on OS X than it ever was before.

-- 
David W. Fentonhttp://www.bway.net/~dfenton
David Fenton Associateshttp://www.bway.net/~dfassoc

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Raymond Horton]

In FINWIN 2005a, I have often extracted a part from a score, then edited 
the part.  Then when I come back to the score, I temporarily see the 
part where the score should be until I do a screen redraw. 

This is as close as I have ever gotten to this bug. 

Is this, by any chance, what you mean by "seen the wrong data displayed 
for the window titles?"

Raymond Horton
David W. Fenton wrote:
On 21 Jan 2005 at 23:15, Jari Williamsson wrote:
 

A-NO-NE Music wrote:
   

Someone pointed out the bug seems to be caused by the array pointer,
and I have the same feeling.
 

As I've said earlier when this have been discussed, the window
handle/ID starts to map to the wrong Enigma Doc ID. I think that's
pretty obvious, but of course that doesn't explain _why_ it happens
and only seem to happen on the Mac.
   

But it *has* happened to *me* on Windows -- I've never lost data, but 
as I've said many times, I've seen the wrong data displayed for the 
window titles (i.e., document names).

 

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[David W. Fenton]

On 21 Jan 2005 at 18:39, Darcy James Argue wrote:

> > I think the people who are blaming memory paging for the corruption
> > have a fundamental misunderstanding of the structure of a modern
> > operating system.
> 
> Just to be clear -- I'm not "blaming memory paging for the corruption"
> and I don't think anyone else here is either.

Not you, Darcy, but others have suggesting paging as a possible 
source of corruption, which is blatantly impossible, unless the OS X 
virtual memory system was improperly designed.

> What I'm suggesting is that Finale stop using the same set of temp
> files for all open documents -- *that* is what's allowing the
> corruption to happen.  Coda says this would cause a performance
> degradation.  However, it would also cause a marked performance
> *boost* if temp files were stored in RAM, not on disk -- we know this
> from the OS 9 days, where everyone who knew what they were doing set
> up a RAM disk for temp files.  This performance boost might well make
> up for the performance hit we'd take by preserving separate temp files
> for each open document.

I don't know what the actual filespace usage of Finale temp files on 
disk because all Windows Explorer reports to me for some of them is 0-
byte size (the files are still open pending writes, so nothing 
definitive is reported; this is often the case with temp files from 
any number of applications -- you can see your disk free space 
dropping but the temp files stay at 0 bytes). It could be that Finale 
uses disk space quite inefficiently for performance reasons, so that 
mapping the same thing into RAM could actually be an order of 
magnitude over what modern systems could handle.

I don't know -- I'm just speculating here.

I do know that the Jet database engine (used by MS Access, for 
instance) uses temp files that can be quite large. It depends on the 
type of operation. A Cartesian join will generate a very large 
temporary data set (since it consists of a join between two tables 
where the number of resulting rows is equal to multiplying the number 
of records in the table by each other; i.e., a Cartesian join of a 
table with 10 rows and a table with 4 rows will have 40 rows). Jet 
temp files can be 100s of megabytes. Put that in RAM and you've got a 
problem.

So, my assumption is that Finale is solving the same kinds of 
problems in temp files instead of in RAM precisely because the space 
needed is quite huge, too large for standard RAM configurations.

> RAM disks aren't a good idea in OS X, so it would be nice if Finale
> offered an option to simply store them in RAM.  If there was
> insufficient physical RAM for this, OS X would simply swap out to
> disk, but then you'd be no worse off than we were before.

If it's in RAM and there's not enough memory, the virtual memory 
subsystem will take care of the memory swapping for you.

> (Of course, they could also just fix the problem where the window
> handle/ID starts to map to the wrong Enigma Doc ID, but apparently
> that's easier said than done.)

Storing temp files in RAM (which is really not using temp files at 
all, of course) would do *nothing* to fix the problem if the problem 
is messed up pointers. If all you're doing is changing whether the 
pointers point to files or pages in RAM, you're not actually 
addressing the fundamental problem at all.

You may get a performance increase.

You may not.

It all depends on exactly what the temp files are being used for.

-- 
David W. Fentonhttp://www.bway.net/~dfenton
David Fenton Associateshttp://www.bway.net/~dfassoc

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[laloba2]

[EMAIL PROTECTED] / 05.1.21 / 00:52 PM wrote:
With Photoshop, it can be helpful to have the temp files stored on a
separate hard drive...not a separate partition but an actual separate
hard drive...things run a little more efficiently that way.  Maybe
this could help Finale too.
The vm stack is created when instruction sets needs a lot of cashing,
while temp file is created the file based caching such as opening huge
file and acquire the undo caching.  But they are separate tasks.
I know...I'm talking about putting the temp files on another disk for 
physical hardware reasons much in the same way that some people put 
their swap files on another drive in earlier versions of the OS 
(much riskier to do in Jag and Panther.)  The less the drive heads on 
the disk have to "run around" to different parts of a disk the faster 
data can be read.

Someone pointed out the bug seems to be caused by the array pointer, and
I have the same feeling.  It shouldn't be related to the amount of the
available memory but rather an address bug.
But I think that if the problem was solely due to an address bug, it 
would happen more often.  And problems with addressing is exactly 
what can happen during a page fault...(when the working set of pages 
of a process, which contains addressing information doesn't have 
enough physical memory...a page fault occursit the OS has enough 
memory to keep the working sets of all processes in physical memory 
there will be fewer page faults.)  Page faults don't occur very 
often.  Only when the system is stressed do they happen more 
frequently...the same goes for the Overwrite Bug.

...related to hacked and twisted code to make Finale work under OSX.
I whole heartedly agree that something has not been coded properly 
under OSX and that that is adding to the problem.  :-)

-Karen
--
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Darcy James Argue]

Hi David,
I think the people who are blaming memory paging for the corruption
have a fundamental misunderstanding of the structure of a modern
operating system.
Just to be clear -- I'm not "blaming memory paging for the corruption" 
and I don't think anyone else here is either.

What I'm suggesting is that Finale stop using the same set of temp 
files for all open documents -- *that* is what's allowing the 
corruption to happen.  Coda says this would cause a performance 
degradation.  However, it would also cause a marked performance *boost* 
if temp files were stored in RAM, not on disk -- we know this from the 
OS 9 days, where everyone who knew what they were doing set up a RAM 
disk for temp files.  This performance boost might well make up for the 
performance hit we'd take by preserving separate temp files for each 
open document.

RAM disks aren't a good idea in OS X, so it would be nice if Finale 
offered an option to simply store them in RAM.  If there was 
insufficient physical RAM for this, OS X would simply swap out to disk, 
but then you'd be no worse off than we were before.

(Of course, they could also just fix the problem where the window 
handle/ID starts to map to the wrong Enigma Doc ID, but apparently 
that's easier said than done.)

- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[David W. Fenton]

On 21 Jan 2005 at 23:15, Jari Williamsson wrote:

> A-NO-NE Music wrote:
> 
> > Someone pointed out the bug seems to be caused by the array pointer,
> > and I have the same feeling.
> 
> As I've said earlier when this have been discussed, the window
> handle/ID starts to map to the wrong Enigma Doc ID. I think that's
> pretty obvious, but of course that doesn't explain _why_ it happens
> and only seem to happen on the Mac.

But it *has* happened to *me* on Windows -- I've never lost data, but 
as I've said many times, I've seen the wrong data displayed for the 
window titles (i.e., document names).

-- 
David W. Fentonhttp://www.bway.net/~dfenton
David Fenton Associateshttp://www.bway.net/~dfassoc

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[David W. Fenton]

On 21 Jan 2005 at 1:23, A-NO-NE Music wrote:

> Just to be clear,
> Only the programmer knows how Finale is paging.  For example, on my:
> 
> Dual-450/1.5GB  37.54MB RAM, 267.98MB vm
> TiBook800/1GB   30.75MB RAM, but only 159MB vm
> 
> FinMac2005a (initial launch, one doc open) on OSX10.3.7 (cold boot)
> Both boot volume has more than 10GB free space for vm.
> 
> So, why less RAM is not acquiring for more vm as expected here?  Only
> the programmer knows.

The programmers of OS X, you mean -- Finale knows nothing about 
virtual memory, which is entirely handled by the operating system's 
virtual memory subsystem.

> By the way, for this testing, I opened the same Finale doc on my
> network at the same time, expecting Finale would give me warning on
> the second machine.  Nope.  It didn't.  I think this is bad.

I think the people who are blaming memory paging for the corruption 
have a fundamental misunderstanding of the structure of a modern 
operating system. To an application like Finale, there is *no* 
discernable difference between real RAM and virtual memory. The OS 
provides a memory pool and is entirely responsible for managing it.

Paging happens when the OS determines that an application needs more 
real memory (i.e., is swapped back into RAM) or is inactive and 
another app needs the real RAM more (pages it out to the swap file on 
disk).

Thrashing happens when conditions are such that the needs of the 
applications for memory are changing faster than the OS can complete 
paging operations, so that by the time a first paging operation has 
completed, conditions have changed and then require additional 
paging. Thrashing should happen only when there is a relatively small 
amount of RAM available and the applications running have aggressive 
memory requirements, including lots of memory pages marked as 
unswappable.

But thrashing should *still* not ever lead to the kind of corruption 
seen in the file overwrite bug, as this would mean that the virtual 
memory subsystem is mucking around with the contents of the pages it 
is swapping, which is something a VM would *never* do!

-- 
David W. Fentonhttp://www.bway.net/~dfenton
David Fenton Associateshttp://www.bway.net/~dfassoc

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Jari Williamsson]

A-NO-NE Music wrote:
Someone pointed out the bug seems to be caused by the array pointer, and
I have the same feeling.
As I've said earlier when this have been discussed, the window handle/ID 
starts to map to the wrong Enigma Doc ID. I think that's pretty obvious, 
but of course that doesn't explain _why_ it happens and only seem to 
happen on the Mac.

Best regards,
Jari Williamsson
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[A-NO-NE Music]

[EMAIL PROTECTED] / 05.1.21 / 00:52 PM wrote:

>With Photoshop, it can be helpful to have the temp files stored on a 
>separate hard drive...not a separate partition but an actual separate 
>hard drive...things run a little more efficiently that way.  Maybe 
>this could help Finale too.

The vm stack is created when instruction sets needs a lot of cashing,
while temp file is created the file based caching such as opening huge
file and acquire the undo caching.  But they are separate tasks.

We all used to put Finale temp files to RAM disk, but was that for
instruction sets, or display cache and undo cache?  I never experimented
Finale performances with Classic OS disk cache allocation.  Has anyone
played with it?  I won't be surprised if the OS9 minimum, that was 1024k
didn't make any difference on Finale performance.

Finale doc is not big as image files.  One might wonder if Finale temp
architecture is way dated.

Someone pointed out the bug seems to be caused by the array pointer, and
I have the same feeling.  It shouldn't be related to the amount of the
available memory but rather an address bug.  It seems to be rather
related to hacked and twisted code to make Finale work under OSX.

My 2 Yen only :-)

-- 

- Hiro

Hiroaki Honshuku, A-NO-NE Music, Boston, MA
 


___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[laloba2]

On 20 Jan 2005, at 07:47 PM, [EMAIL PROTECTED] wrote:
Finale uses a lot of memory I have noticed.  It uses a lot of 
shared memory too which leads me to believe that the new graphics 
are using up a lot of memory.  I personally would trade the nice 
graphics for having the program use less memory.
I don't think that's really an option in OS X.  And I would like to 
see Finale take *better* advantage of OS X graphics (i.e., Core 
Image), rather than go the low-res route.  This is not incompatible 
with improved performance -- in fact, if it was implemented well, 
like in Sibelius, proper Core Image support would not only improve 
the image quality, but improve the speed tremendously as well. 
Finale's drawing engine is in drastic need of an overhaul in any 
event.
That makes sense...and that would explain why it looks like Finale is 
so inefficient when it comes to the graphics.


And there's got to be a better way to handle the temp file thing.
Well, there's storing them in RAM, but that would require *more* 
memory.  I'm okay with that, though, especially if it's available as 
a Program Option.  As you said, 1 GB of RAM is getting to be the new 
standard minimum requirement.  (Although, in the case of my 
[hopefully soon-to-be-delivered] Mac mini, that's also the *maximum* 
memory... ).  However, it's my experience that temp files rarely 
exceed 15 MB, so the additional memory requirements shouldn't be 
*that* onerous.  And, of course, if the user runs out of room, just 
let the OS handle it by paging out to HD.  No reason to store them 
on the HD by *default*, though -- that just slows down an already 
tremendously sluggish app.

Another potential advantage to storing the temp files in RAM (in 
addition to the speed boost) is that perhaps if the files are stored 
in RAM, it would no longer be necessary to have all the currently 
open documents share temp files -- which seems to be the source of 
the problem.
You have really hit on something with all of this Darcy.  Perhaps 
storing the temp files on a second hard drive might help a little bit 
too...which of course can be done through preferences.  It is 
possible to create a RAM disk in OS X...though people get really 
nervous even bringing this up.   But if one has a lot of RAM in a 
machine and they are sure that there is enough elbow room to make 
sure that the RAM disk isn't stepping on the toes of the the OS's 
lovely memory handling choreography, it can be effective under 
certain circumstances.  Maybe this is one of them.

Coda says they have to do that to improve performance -- well, I bet 
having separate temp files for each document, but storing them in 
RAM instead of the HD, would at the very least result in no net 
performance loss.
I think there are many other things that MM can do to improve 
performance...as you have mentioned throughout this post. :-)  They 
were really late to the party as far as OS X goes.  The sad thing is 
that Apple is really great about supporting outside developers. 
There are people there whose only job is to assist developers in 
things like understanding the OS and even things that the developer 
needs from Apple to help with writing of applications.  So MM could 
really be taking advantage of this to better the program to make it 
work more efficiently.

-K
--
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[laloba2]

Christopher Smith / 05.1.20 / 08:32 AM wrote:
There's a kicker. I usually have a bunch of stuff open at the same
time, like AppleWorks, Mail, Safari, TextEdit, Preview, and maybe Word
or Excel. I typically only quit one of the first five apps or Finale
when it acts up (rare these days in OS X) or if I have to reboot. My
computer is often on for weeks at a time without being turned off or
 >rebooted.

Just to be clear,
Only the programmer knows how Finale is paging.  For example, on my:
Dual-450/1.5GB  37.54MB RAM, 267.98MB vm
TiBook800/1GB   30.75MB RAM, but only 159MB vm
FinMac2005a (initial launch, one doc open) on OSX10.3.7 (cold boot)
Both boot volume has more than 10GB free space for vm.
So, why less RAM is not acquiring for more vm as expected here?  Only the
programmer knows.

While Finale paging might not be related to this problem, since we are
here :-)
Perhaps...but I'm not talking about the day to day use of VM as far 
as this problem goes.  Of course things are being written back and 
forth during the normal operation of the machine and you are 
right...and yes, only the programmer knows exactly how finale is 
programmed to be handling these things though I'm really curious :-). 
But, my best guess is that the problem comes in when memory resources 
are stretched so thin that the working set of memory pages of the 
various active processes no longer have room to reside in the 
physical RAM where they need to be for things to run effectively. 
That's when the thrashing begins.  If the problem was caused by 
normal use of VM, I think the "bug" would "bite" more often rather 
than just when the system was stressed.


You might want to consider rebooting OSX time to time because the number
of swapfile will not go away less than 4 or 5 until you reboot.  OSX
needs about 1GB free space for vm stack, which can be eaten up quickly
when swapfile() accumulates 6-7 of them,
I agree that rebooting more often is a good idea.
and Safari can do that as well
as Photoshop.  Oh, iPhoto is probably the worst.
With Photoshop, it can be helpful to have the temp files stored on a 
separate hard drive...not a separate partition but an actual separate 
hard drive...things run a little more efficiently that way.  Maybe 
this could help Finale too.

Also, forgive me if you already know this, when you are running 'top',
you need to ignore inactive portion.  They are addressed alright, but
they are not occupied.
Right...I'm mostly concerned with PhysMem: M's free, VM: pageouts, at 
least for watching for system stress.

-K
--
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[A-NO-NE Music]

Christopher Smith / 05.1.20 / 08:32 AM wrote:

>There's a kicker. I usually have a bunch of stuff open at the same 
>time, like AppleWorks, Mail, Safari, TextEdit, Preview, and maybe Word 
>or Excel. I typically only quit one of the first five apps or Finale 
>when it acts up (rare these days in OS X) or if I have to reboot. My 
>computer is often on for weeks at a time without being turned off or 
>rebooted.


While Finale paging might not be related to this problem, since we are
here :-)

You might want to consider rebooting OSX time to time because the number
of swapfile will not go away less than 4 or 5 until you reboot.  OSX
needs about 1GB free space for vm stack, which can be eaten up quickly
when swapfile() accumulates 6-7 of them, and Safari can do that as well
as Photoshop.  Oh, iPhoto is probably the worst.

Also, forgive me if you already know this, when you are running 'top',
you need to ignore inactive portion.  They are addressed alright, but
they are not occupied.


-- 

- Hiro

Hiroaki Honshuku, A-NO-NE Music, Boston, MA
 


___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[A-NO-NE Music]

Just to be clear,
Only the programmer knows how Finale is paging.  For example, on my:

Dual-450/1.5GB  37.54MB RAM, 267.98MB vm
TiBook800/1GB   30.75MB RAM, but only 159MB vm

FinMac2005a (initial launch, one doc open) on OSX10.3.7 (cold boot)
Both boot volume has more than 10GB free space for vm.

So, why less RAM is not acquiring for more vm as expected here?  Only the
programmer knows.

By the way, for this testing, I opened the same Finale doc on my network
at the same time, expecting Finale would give me warning on the second
machine.  Nope.  It didn't.  I think this is bad.



-- 

- Hiro

Hiroaki Honshuku, A-NO-NE Music, Boston, MA
 


___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Darcy James Argue]

On 20 Jan 2005, at 07:47 PM, [EMAIL PROTECTED] wrote:
Finale uses a lot of memory I have noticed.  It uses a lot of shared 
memory too which leads me to believe that the new graphics are using 
up a lot of memory.  I personally would trade the nice graphics for 
having the program use less memory.
I don't think that's really an option in OS X.  And I would like to see 
Finale take *better* advantage of OS X graphics (i.e., Core Image), 
rather than go the low-res route.  This is not incompatible with 
improved performance -- in fact, if it was implemented well, like in 
Sibelius, proper Core Image support would not only improve the image 
quality, but improve the speed tremendously as well.  Finale's drawing 
engine is in drastic need of an overhaul in any event.

And there's got to be a better way to handle the temp file thing.
Well, there's storing them in RAM, but that would require *more* 
memory.  I'm okay with that, though, especially if it's available as a 
Program Option.  As you said, 1 GB of RAM is getting to be the new 
standard minimum requirement.  (Although, in the case of my [hopefully 
soon-to-be-delivered] Mac mini, that's also the *maximum* memory... ).  
However, it's my experience that temp files rarely exceed 15 MB, so the 
additional memory requirements shouldn't be *that* onerous.  And, of 
course, if the user runs out of room, just let the OS handle it by 
paging out to HD.  No reason to store them on the HD by *default*, 
though -- that just slows down an already tremendously sluggish app.

Another potential advantage to storing the temp files in RAM (in 
addition to the speed boost) is that perhaps if the files are stored in 
RAM, it would no longer be necessary to have all the currently open 
documents share temp files -- which seems to be the source of the 
problem.  Coda says they have to do that to improve performance -- 
well, I bet having separate temp files for each document, but storing 
them in RAM instead of the HD, would at the very least result in no net 
performance loss.

And it would help squash this maddening bug, which frankly makes Finale 
look like it was coded by complete amateurs.  What other $500 
application can't handle basic stuff managing multiple open documents 
without corrupting them?

- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[laloba2]

On Jan 20, 2005, at 12:46 AM, [EMAIL PROTECTED] wrote:
(lots of computer talk snipped)
So the questions I am still curious about are:
Is this a Mac specific issue?  If not can the problem be replicated 
on a windows machine and under what circumstances?

The only people I know of reporting this bug are Mac users.
Hi Christopher,
Thank you for this info...:-)
My hunch is that this is a mac issue...there may be similar issues in 
Windows as David mentioned but I think this particular issue may be 
mac specific.


How much RAM and hard disk space do people have on the machines 
where this is occurring?

I have 768 megs of Ram, and a large number of gigs of hard drive space.

How many other apps are running at the time this happens?
There's a kicker. I usually have a bunch of stuff open at the same 
time, like AppleWorks, Mail, Safari, TextEdit, Preview, and maybe 
Word or Excel.
You have 128M more RAM on your machine than I do on the machine I am 
testing this on.  When I open all of the applications you mentioned 
and then open Finale and a few files, the free memory drops way down 
and my machine starts paging (moving data from the physical memory to 
disk.)  Since you have and extra 128M  you have a little more elbow 
room but that can get eaten up pretty quickly by opening files within 
those applications.  On my machine, I got to the paging stage with no 
other files open (pictures, PDF's etc.) in the other 
applicationsjust files open in Finale.  Add PDF's pics etc in and 
I'll bet you are getting low on free memory.  Additionally, if there 
is a memory leak anywhere (up until 10.3.5 at least, Safari was 
rumored to have this problem) then your free RAM would be drifting 
down further over time until there is a restart.

I typically only quit one of the first five apps or Finale when it 
acts up (rare these days in OS X) or if I have to reboot. My 
computer is often on for weeks at a time without being turned off or 
rebooted.
So, at some point, over time, the system starts thrashing, or as you 
said, Finale acts up, which may be a clue that paging is occurring. 
Info is now being written from RAM to disk, and we don't know which 
information is being written to disk.  If it happens to temp files or 
the pointer tables as David mentioned (I still don't quite understand 
how Finale's temp files are working exactly) then there is a problem. 
Also, if one sees a temp file "hanging"(I've seen this before) 
then perhaps that is another clue.  Accessing files from disk is 
slower than accessing them from RAM.  Which goes back to what Darcy 
was talking about.

So I guess the fix can be many things.  The easiest thing is to have 
fewer apps open while working in Finale especially when working on 
multiple large files at the same time.  But there is also adding more 
RAM (it is getting so that a gig of RAM is the minimum I want to have 
on my machine...my other machine has 2 Gigs and I need to buy more 
for the one I'm working on now), restarting more often and making 
sure cron scripts are being run (daily, weekly, and monthly.)  If 
your computer is being put to sleep overnight or is shut down much of 
the time, these may not be running.  I use Cocktail for this but 
there is also MacJanitor which is free and can do the job.   The 
terminal can also be used for this.  Type "sudo periodic daily weekly 
monthly" (no quotes) and hit return.  Type your admin password and 
the scripts will run.  Doing this once a week may help.

Finale uses a lot of memory I have noticed.  It uses a lot of shared 
memory too which leads me to believe that the new graphics are using 
up a lot of memory.  I personally would trade the nice graphics for 
having the program use less memory.  And there's got to be a better 
way to handle the temp file thing.

-K

--
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[David W. Fenton]

On 20 Jan 2005 at 8:32, Christopher Smith wrote:

> On Jan 20, 2005, at 12:46 AM, [EMAIL PROTECTED] wrote:
> 
> (lots of computer talk snipped)
> 
> > So the questions I am still curious about are:
> >
> > Is this a Mac specific issue?  If not can the problem be replicated
> > on a windows machine and under what circumstances?
> 
> The only people I know of reporting this bug are Mac users.

Well, I've experienced similar bugs on Windows, though not identical.

And I experienced it in WinFin97 and still have it happen 
occasionally in WinFin2K3.

I've never lost any data, but I have noticed that switching between 
document windows I have sometimes seen document windows display the 
content from another open document (e.g., with File1.mus, File2.mus 
and File3.mus open, sometimes the window titled File1.mus was 
actually displaying the content of File2.mus).

> > Are Temp files handled the same or differently in MacFinale and
> > WinFinale?
> 
> Ummm...

I think there's much in common in *Finale's* use of temp files on 
both platforms, at least based on what people have described on the 
list.

-- 
David W. Fentonhttp://www.bway.net/~dfenton
David Fenton Associateshttp://www.bway.net/~dfassoc

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Christopher Smith]

On Jan 20, 2005, at 12:46 AM, [EMAIL PROTECTED] wrote:
(lots of computer talk snipped)
So the questions I am still curious about are:
Is this a Mac specific issue?  If not can the problem be replicated on 
a windows machine and under what circumstances?

The only people I know of reporting this bug are Mac users.

Are Temp files handled the same or differently in MacFinale and 
WinFinale?

Ummm...

How much RAM and hard disk space do people have on the machines where 
this is occurring?

I have 768 megs of Ram, and a large number of gigs of hard drive space.

How many other apps are running at the time this happens?
There's a kicker. I usually have a bunch of stuff open at the same 
time, like AppleWorks, Mail, Safari, TextEdit, Preview, and maybe Word 
or Excel. I typically only quit one of the first five apps or Finale 
when it acts up (rare these days in OS X) or if I have to reboot. My 
computer is often on for weeks at a time without being turned off or 
rebooted.


What do the system resource numbers look like after the Overwrite Bug 
strikes?

I will look next time.
Christopher
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[laloba2]

You should be able to figure out how much RAM Finale is using by
using your OS's version of TOP (on Windows you can use the Task
Manager for that). You should check RAM using before loading Finale,
RAM usage after loading Finale with no files, then check RAM usage as
you open more and more files, then close all files and check RAM
usage.
I have been running top..through the terminal application.  After 
opening several files, the RAM usage increased by around 35-40% which 
I thought was significant.  But that isn't the whole picture IMHO.

One also has to look at how the system is running...especially how 
much free RAM is available.  And numbers can be deceptive here...it 
can look like the memory handling system in OS X is taking care of 
everything correctly while at the same time things will get sluggish 
and not work quite right...

When  I opened Finale there was quite a drop in free RAM and after 
opening several files, the free RAM got low enough to cause paging. 
(I intentionally have several apps open as I am doing this because I 
do have a good amount of RAM in my machine and I need to push it in 
order to see what is happening if I open Finale with a system that is 
already stressedin otherwords...to cause my machine to behave as 
a machine with less RAM would behave)

These drops in free RAM in OS X have also been reported due to memory 
leaks coming from somewhere...I've heard of it happening with apps 
that have code issues and sometimes with printer drivers.  I haven't 
seen any memory leaks with Finale up to this point however.  But I 
haven't really tested it.

I very strongly doubt that this has anything to do with system
resources and has everything to do with the very odd Finale temp file
architecture that mixes content from multiple files within a single
temp file.
I agree with you that there is a problem with the temp file 
architecture in Finale...and BTW thank you for answering a question I 
had about that...I was wondering what was different about Finale temp 
files...:-) 

The only thing required to then produce the bug (i.e.,
content from the wrong file) is for the pointer table that maps open
files to temp files to get messed up.
I agree...but this is the part that I'm wondering aboutand this 
is the part that I think may be RAM related...when free RAM is low in 
OS X, all sorts of things can go haywire (I used the example of 
Preferences not being saved correctly under these circumstances...) 
I'm wondering if this can in some way cause the mess up you are 
talking about...

[]
 This may explain why Finale is faster after a restart and why it seems
 that temp files are becoming bloated/corrupted after a long Finale
 session.  It may not be the files themselves but rather that more
 paging has occured over a long session as OS X tries to juggle memory
 resources.
It's probably not paging.
It actually is pagingI can see it happening through the top 
command in Terminal.  I pushed my system until I had 108M of free 
RAM.  After opening Finale that number dropped to 65M and then when I 
opened several documents it dropped to 7M.  It was when free RAM got 
low that the system started paging.  Again, I have to push my system 
by opening several other apps to get it to do this, but a system with 
less RAM would reach this point without a bunch of other apps open. 
Or in the case that there was a memory leak somewhere.  Or even after 
a long "computer session" under some circumstances.

..but the amount of
churning people are describing with temp files leads me to believe
that somewhere in the temp file handling, there's some process that
is subject to this kind of churn effect.
You may be right..but, in addition, there is also something in Mac 
Land called "Thrashing" that causes these same symptoms and is due to 
a machine needing more RAM and/or more hard disk space.  I'm thinking 
it could be a combination of things going on.

And the fact that Darcy mentioned this:
I noticed a *drastic* performance improvement when I quit and 
restart Finale compared to what I was getting during the session 
where the File Overwrite bug hit, despite having exactly the same 
set of files open as I did before.  Redraws were easily twice as 
fast.
makes me thing that it is at least partially systemic...I don't think 
that the Temp files were doing anything differently after the 
restart.  But if it was a resource problem, a restart would help.

So the questions I am still curious about are:
Is this a Mac specific issue?  If not can the problem be replicated 
on a windows machine and under what circumstances?

Are Temp files handled the same or differently in MacFinale and WinFinale?
How much RAM and hard disk space do people have on the machines where 
this is occurring?

How many other apps are running at the time this happens?
What do the system resource numbers look like after the Overwrite Bug strikes?
-K


--
___
Finale mailing list
F

Re: [Finale] File Overwrite Bug in Action

[David W. Fenton]

On 19 Jan 2005 at 12:16, [EMAIL PROTECTED] wrote:

[]

> I'm now suspecting that when one has many files open at the same time,
> (or in my case, when many people are working off one server) and auto
> saves are happening, along with regular saves and the whole temp file
> thing that Finale requires a ton of RAM, perhaps more so than other
> apps that don't have some of these features or ways of dealing with
> temp files (sorry if this seems obvious)

You should be able to figure out how much RAM Finale is using by 
using your OS's version of TOP (on Windows you can use the Task 
Manager for that). You should check RAM using before loading Finale, 
RAM usage after loading Finale with no files, then check RAM usage as 
you open more and more files, then close all files and check RAM 
usage.

My bet is that you'll see VERY LITTLE DIFFERENCE -- that's the whole 
point of temp files, that all the temporary stuff is written out to 
disk and only the current workset is kept in memory. Yes, as the 
number of files open increases the size of the pointer table that 
connects files open to temp files will increase, but that's, memory-
wise, a very small thing.

> The way that OS X deals with memory or lack thereof is interesting.
> When the OS is out of RAM it starts to copying data from RAM to the
> Hard disk (this is called paging) The file that the OS copies to on
> the hard disk (I should be more specific...boot disk) is called
> a...don't laugh...a swap file.  This process is the virtual memory
> part of OS X.

Er, um, all current versions of Windows have been doing that since, 
oh, 1994 (NT 3.1 came out in 1991, and, naturally, had pageable 
virtual memory; 1994 is the date of the release of Windows for 
Workgroups; even previous versions of Win3.1x had pageable swap 
files, but the virtual memory system as a whole was not nearly as 
robust).

Every modern operating system has always supported virtual memory 
paging. The Mac OS was the last "modern" OS to get it, and because it 
was bolted onto an architecture that wasn't designed for it, it often 
caused problems. OS X being based on a UNIX variant was designed from 
the ground up with that kind of thing in mind.

> So, I'm wondering if there is some sort of confusion somewhere with
> what is getting copied to/from what when the system resources are
> taxed thus creating the Overwrite Bug. . . .

I very strongly doubt that this has anything to do with system 
resources and has everything to do with the very odd Finale temp file 
architecture that mixes content from multiple files within a single 
temp file. The only thing required to then produce the bug (i.e., 
content from the wrong file) is for the pointer table that maps open 
files to temp files to get messed up.

[]

> This may explain why Finale is faster after a restart and why it seems
> that temp files are becoming bloated/corrupted after a long Finale
> session.  It may not be the files themselves but rather that more
> paging has occured over a long session as OS X tries to juggle memory
> resources.

It's probably not paging. It's just that writing to temp is orders of 
magnitude slower than writing to RAM, especially if you're having to 
write certain things in order. That is, if the file needs to be 
maintained with blocks in certain order, e.g., block A, block B and 
block C, and say that block A outgrows the allocated file space. Then 
to write block A, at the very least, at least some sectors of block B 
(and possibly all of block B and some or all of block C) will need to 
be rewritten, as well. 

Now, that scenario has probably been planned for, but the amount of 
churning people are describing with temp files leads me to believe 
that somewhere in the temp file handling, there's some process that 
is subject to this kind of churn effect.

But I strongly doubt the whole set of problems have anything to do 
with RAM or virtual memory, both of which are completely transparent 
to Finale and should never cause any kinds of problems for the 
application -- if it's a problem, the app just grinds to a halt -- it 
would never lead to the corruption of structures internal to the 
program (the virtual memory subsystem knows nothing about the content 
of the memory pages being swapped).

-- 
David W. Fentonhttp://www.bway.net/~dfenton
David Fenton Associateshttp://www.bway.net/~dfassoc

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[David W. Fenton]

On 19 Jan 2005 at 8:18, Darcy James Argue wrote:

> Could there be a problem not only with the File Overwrite bug, but
> with the Finale Temp Files getting bloated/corrupted over the course
> of an extended Finale session, causing performance degradation AND
> problems such as the File Overwrite bug?

There is unquestionably a connection, as the way Finale temp files 
work is that there is a group of temp files that is shared by all the 
files that are open. This means that each temp file contains parts of 
several different files. When it was explained on the list, the 
justification was that this greatly increased performance when 
copying between files (since it was all happen within the same temp 
files).

I know of no other applications that use temp files in this fashion, 
and it seems obvious to me that the pointers that keep track of which 
pages of which temp files belong to which real files are getting 
messed up somehow. Of course, identifying the likely cause is likely 
saying the cause of death of a person was a gunshot to the head -- it 
still doesn't tell you who pulled the trigger.

> Please let me once again repeat my request to do away with temp files
> and instead have Finale store that information in RAM -- at least as
> an option.  (We used to be able to do that in OS 9 with a RAM Disk,
> but RAM disks aren't effective in OS X.)

RAM disks wouldn't change anything at all, since it would just be 
moving the temp files from a physical drive to a virtual drive in 
memory.

> It seems like many of the stability and corruption problems in Finale
> have to do with the way it handles temp files, which are a bit of an
> anachronism in any case.  Perhaps some of these problems could be
> solved by using RAM instead of disk space?

I can't think of any non-trivial application that I use on a regular 
basis that does not uses temp files. In the case of database 
applications (which is what Finale is), it's definitely part of the 
only workable architecture because of commit/rollback issues.

In short, there's nothing old-fashioned about temp files at all.

-- 
David W. Fentonhttp://www.bway.net/~dfenton
David Fenton Associateshttp://www.bway.net/~dfassoc

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[laloba2]

Hi Darcy,
The points you brought up regarding Temp files and RAM Disks got me 
thinking.  I'm wondering now if this overwrite bug has to do with how 
RAM intensive Finale isand especially with all the saving 
features (auto save, backups, temp files...)  Since the overwrite bug 
occurs under different circumstances (task wise), the common 
denominator in my opinion may have to do with how Finale is working 
with the OS and hardware in ones computer.  I am also very curious as 
to how Finale is handling temp files.

I'm now suspecting that when one has many files open at the same 
time, (or in my case, when many people are working off one server) 
and auto saves are happening, along with regular saves and the whole 
temp file thing that Finale requires a ton of RAM, perhaps more so 
than other apps that don't have some of these features or ways of 
dealing with temp files (sorry if this seems obvious)

The way that OS X deals with memory or lack thereof is interesting. 
When the OS is out of RAM it starts to copying data from RAM to the 
Hard disk (this is called paging) The file that the OS copies to on 
the hard disk (I should be more specific...boot disk) is called 
a...don't laugh...a swap file.  This process is the virtual memory 
part of OS X.

So, I'm wondering if there is some sort of confusion somewhere with 
what is getting copied to/from what when the system resources are 
taxed thus creating the Overwrite Bug.  Interestingly enough...low 
system resources, either RAM or hard disk space, can also cause 
problems with certain apps, depending on how/when the access their 
preferences, not saving Preferences correctly or having prefs being 
reset to "default" totally or partially after the app is relaunched.

This may explain why Finale is faster after a restart and why it 
seems that temp files are becoming bloated/corrupted after a long 
Finale session.  It may not be the files themselves but rather that 
more paging has occured over a long session as OS X tries to juggle 
memory resources.

To test this, you can try this...open your terminal application and 
type "top" (no quote marks) You'll see something that looks like this 
at the top of the window.  when you are done, to exit this 
terminal process, type ctrl-C and then you can quit the terminal 
app.**

Processes:  50 total, 3 running, 47 sleeping... 131 threads11:52:30
Load Avg:  2.45, 1.30, 0.55 CPU usage:  27.3% user, 29.7% sys, 43.0% idle
SharedLibs: num =  110, resident = 23.3M code, 2.80M data, 9.76M LinkEdit
MemRegions: num =  5306, resident = 67.2M + 11.8M private, 53.5M shared
PhysMem:  65.7M wired, 99.8M active,  109M inactive,  275M used,  364M free
VM: 3.03G + 74.4M   15476(0) pageins, 0(0) pageouts
The two lines one is concerned with are the bottom twothese are 
Physical memory and Virtual memory (VM)  Look at the last numbers of 
each line

PhysMem:  65.7M wired, 99.8M active,  109M inactive,  275M used,  364M free
VM: 3.03G + 74.4M   15476(0) pageins, 0(0) pageouts
You should have plenty of Free PhysMem and a low pageouts 
number...0(0) means that my RAM has not been exhausted as of yet and 
therefore paging has not yet occurred.  (I got these numbers after a 
restart with only a couple of apps running.)  If one has enough RAM 
in the machine, free space will obviously be high and the pageouts 
will stay low...if there is not enough RAM, then the opposite will be 
true.(i.e. 7.7M free for PhysMem and 876543(0) for pageouts for 
example)  I might suggest running this terminal command after you 
have been visited by the Overwrite Bug.

However, all this is not to say that Finale isn't contributing to the 
problem if this whole memory thing holds water.   As I mentioned in 
the beginning of this post, I'm curious as to how Finale uses RAM, if 
it is efficient or not and how much more RAM is needed with features 
like auto save set up.

-K


Hey Allen & co,
One more thing:
I noticed a *drastic* performance improvement when I quit and 
restart Finale compared to what I was getting during the session 
where the File Overwrite bug hit, despite having exactly the same 
set of files open as I did before.  Redraws were easily twice as 
fast.

Could there be a problem not only with the File Overwrite bug, but 
with the Finale Temp Files getting bloated/corrupted over the course 
of an extended Finale session, causing performance degradation AND 
problems such as the File Overwrite bug?

Please let me once again repeat my request to do away with temp 
files and instead have Finale store that information in RAM -- at 
least as an option.  (We used to be able to do that in OS 9 with a 
RAM Disk, but RAM disks aren't effective in OS X.)

It seems like many of the stability and corruption problems in 
Finale have to do with the way it handles temp files, which are a 
bit of an anachronism in any case.  Perhaps some of these problems 
could be solved by using RAM instead of disk space?

- Darcy
-
[EMAIL

Re: [Finale] File Overwrite Bug in Action

[Chuck Israels]

Dear Darcy,

You know, I might be experiencing similar degradation after long Finale sessions,  I think things slow down a little, and then I begin to get the Finale icon covering the selected tool in the pallet (instead of just a highlight).  I've become so used to this that I hardly notice and have attributed this to my system, rather than to Finale, but I think I'm getting similar results and problems.

A restart always brings things back to normal.

Chuck

On Jan 19, 2005, at 5:18 AM, Darcy James Argue wrote:

Hey Allen & co,

One more thing:

I noticed a *drastic* performance improvement when I quit and restart Finale compared to what I was getting during the session where the File Overwrite bug hit, despite having exactly the same set of files open as I did before.  Redraws were easily twice as fast.

Could there be a problem not only with the File Overwrite bug, but with the Finale Temp Files getting bloated/corrupted over the course of an extended Finale session, causing performance degradation AND problems such as the File Overwrite bug?

Please let me once again repeat my request to do away with temp files and instead have Finale store that information in RAM -- at least as an option.  (We used to be able to do that in OS 9 with a RAM Disk, but RAM disks aren't effective in OS X.)

It seems like many of the stability and corruption problems in Finale have to do with the way it handles temp files, which are a bit of an anachronism in any case.  Perhaps some of these problems could be solved by using RAM instead of disk space?

- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY

On 19 Jan 2005, at 08:07 AM, Darcy James Argue wrote:

Damn -- I thought I had dodged the problem, but I got bit by it anyway -- on a different file!

Here's the MacSupport note:

Hi Allen & co.,

Just an update -- when I noticed the printing problem with the last file, I tried opening a second instance of the file (without quitting Finale), which fixed the problem.  However, I continued to work without quitting Finale, until just a moment ago, when it abruptly became impossible to select anything with any tool.

I went through each file one by one and manually saved it and closed it.  Then I quit Finale.  When I relaunched Finale, the file I had been working on when the problem with selecting things occurred had been replaced with different content.  I have attached it here:

[attachment deleted]

It was originally a chorus part with piano reduction, but it's been replaced with the content of the Harp part for this piece.  I don't know if you can glean anything from this file, but take a look and see if it tells you anything.

For comparison purposes, here is the most recent auto-saved version of the same file:

[attachment deleted]

Let me know if I can give you any other info that might help pin this down.

Cheers,

- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY

CC: of message I sent to Allen and MacSupport, minus the attached files:

Hi Allen, guys,

Allen, I know you're going to NAMM but hopefully you get a chance to look at this when you get back.

I think I may have an instance of the File Overwrite bug in action.  This is in Fin2005a.  I have 22 documents open.  The frontmost document -- "08 The Gallows 2005.mus" -- is *displaying* the *content* of that file (a score), but when I go to print, the file that actually prints is a different (also currently open) file -- "WitCan - 002 Percussion 2005.mus" ( a part).  I have confirmed this printing error twice.

I am sending you both files in their current states.  When you open "08 The Gallows 2005.mus," does it look like a score, or a part?  When you print it, does the printout match the screen contents, or does it print a percussion part instead?

UPDATE: when I open a second instance of the part, it prints correctly.  I'm going to save the problematic instance under a different name and see what happens.

- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY

___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale


Chuck Israels
230 North Garden Terrace
Bellingham, WA 98225-5836
phone (360) 671-3402
fax (360) 676-6055
www.chuckisraels.com
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Christopher Smith]

Darcy,
I, too was recently hit by the bug, Jan 14 to be precise. It was the 
middle of the day, so I froze everything as soon as I noticed it, and 
sent the message below. I had 14 files open. However, one thing I 
noticed in this case - even though the score was showing Trombone 2, 
when I switched to Scroll View, everything was there as it was supposed 
to be (see the paragraph starting with "Crap". That, to my knowledge, 
has not happened before, though to be fair, I never switched views 
before when I had noticed a corrupted score file.

Christopher

Here is the message I sent to Allen and Macsupport.
Hi all,
I have sitting in front of me right now on my computer full proof of 
the file overwrite bug, as it occurred in FInMAc 2005a. I haven't 
touched anything, as far as I know, since it happened. Is there 
anything you would like me to check while the file is open? The state 
of my temps files? Text block ID's?

I had extracted parts last night from an orchestra score (based on an 
old file, if that means anything), opening them all at once 
automatically.  I cleaned up and printed the first three (including 
changing the page 2 text block to include the instrument name), then 
Finale started acting wonky (strange things highlighted on the screen, 
command opt [ would not work along with some other key commands) so I 
quit without saving anything. This morning I started again. The 
computer had been on all night. I re-opened Finale, this time with only 
half the parts opened, and worked apparently without incident. During 
the first part I worked on I was testing out the TG Tools Process 
Extracted Parts plugin, and in the process of expermenting I selected 
the Horn 3+4 staff in the SCORE, copied it with the Mass Mover, and 
pasted it into the open part file. This took a little longer than I am 
used to, but it worked. I hid (yellow button) the score file while I 
continued working.

A few parts later I worked on Trombone 2, but I didn't notice any 
problems at the time, even though THIS appears to be when the bug hit. 
Everything proceeded normally from then on, including opening up the 
second batch of part files and editing and printing and saving them. 
When I un-hid the score file, it turned out to be the Trombone 2 part, 
even though the file name was still that of the score.

Crap! I just now looked at the score file, and when I changed to Scroll 
View, the entire score was there, unchanged! When I switched back to 
Page view, the score was back too, apparently normal. What happened? 
Why would a file appear to have different contents one time, then 
change when I change views?

I have saved it under a different name, just for comparison.
Waiting to hear from you.
Christopher Smith
On Jan 19, 2005, at 2:24 AM, Darcy James Argue wrote:
CC: of message I sent to Allen and MacSupport, minus the attached 
files:

Hi Allen, guys,
Allen, I know you're going to NAMM but hopefully you get a chance to 
look at this when you get back.

I think I may have an instance of the File Overwrite bug in action.  
This is in Fin2005a.  I have 22 documents open.  The frontmost 
document -- "08 The Gallows 2005.mus" -- is *displaying* the *content* 
of that file (a score), but when I go to print, the file that actually 
prints is a different (also currently open) file -- "WitCan - 002 
Percussion 2005.mus" ( a part).  I have confirmed this printing error 
twice.

I am sending you both files in their current states.  When you open 
"08 The Gallows 2005.mus," does it look like a score, or a part?  When 
you print it, does the printout match the screen contents, or does it 
print a percussion part instead?

UPDATE: when I open a second instance of the part, it prints 
correctly.  I'm going to save the problematic instance under a 
different name and see what happens.

- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] File Overwrite Bug in Action

[Darcy James Argue]

Hey Allen & co,
One more thing:
I noticed a *drastic* performance improvement when I quit and restart 
Finale compared to what I was getting during the session where the File 
Overwrite bug hit, despite having exactly the same set of files open as 
I did before.  Redraws were easily twice as fast.

Could there be a problem not only with the File Overwrite bug, but with 
the Finale Temp Files getting bloated/corrupted over the course of an 
extended Finale session, causing performance degradation AND problems 
such as the File Overwrite bug?

Please let me once again repeat my request to do away with temp files 
and instead have Finale store that information in RAM -- at least as an 
option.  (We used to be able to do that in OS 9 with a RAM Disk, but 
RAM disks aren't effective in OS X.)

It seems like many of the stability and corruption problems in Finale 
have to do with the way it handles temp files, which are a bit of an 
anachronism in any case.  Perhaps some of these problems could be 
solved by using RAM instead of disk space?

- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY
On 19 Jan 2005, at 08:07 AM, Darcy James Argue wrote:
Damn -- I thought I had dodged the problem, but I got bit by it anyway 
-- on a different file!

Here's the MacSupport note:
Hi Allen & co.,
Just an update -- when I noticed the printing problem with the last 
file, I tried opening a second instance of the file (without quitting 
Finale), which fixed the problem.  However, I continued to work 
without quitting Finale, until just a moment ago, when it abruptly 
became impossible to select anything with any tool.

I went through each file one by one and manually saved it and closed 
it.  Then I quit Finale.  When I relaunched Finale, the file I had 
been working on when the problem with selecting things occurred had 
been replaced with different content.  I have attached it here:

[attachment deleted]
It was originally a chorus part with piano reduction, but it's been 
replaced with the content of the Harp part for this piece.  I don't 
know if you can glean anything from this file, but take a look and see 
if it tells you anything.

For comparison purposes, here is the most recent auto-saved version of 
the same file:

[attachment deleted]
Let me know if I can give you any other info that might help pin this 
down.

Cheers,
- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY
CC: of message I sent to Allen and MacSupport, minus the attached 
files:

Hi Allen, guys,
Allen, I know you're going to NAMM but hopefully you get a chance to 
look at this when you get back.

I think I may have an instance of the File Overwrite bug in action.  
This is in Fin2005a.  I have 22 documents open.  The frontmost 
document -- "08 The Gallows 2005.mus" -- is *displaying* the 
*content* of that file (a score), but when I go to print, the file 
that actually prints is a different (also currently open) file -- 
"WitCan - 002 Percussion 2005.mus" ( a part).  I have confirmed this 
printing error twice.

I am sending you both files in their current states.  When you open 
"08 The Gallows 2005.mus," does it look like a score, or a part?  
When you print it, does the printout match the screen contents, or 
does it print a percussion part instead?

UPDATE: when I open a second instance of the part, it prints 
correctly.  I'm going to save the problematic instance under a 
different name and see what happens.

- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

[Finale] File Overwrite Bug in Action

[Darcy James Argue]

Damn -- I thought I had dodged the problem, but I got bit by it anyway 
-- on a different file!

Here's the MacSupport note:
Hi Allen & co.,
Just an update -- when I noticed the printing problem with the last 
file, I tried opening a second instance of the file (without quitting 
Finale), which fixed the problem.  However, I continued to work without 
quitting Finale, until just a moment ago, when it abruptly became 
impossible to select anything with any tool.

I went through each file one by one and manually saved it and closed 
it.  Then I quit Finale.  When I relaunched Finale, the file I had been 
working on when the problem with selecting things occurred had been 
replaced with different content.  I have attached it here:

[attachment deleted]
It was originally a chorus part with piano reduction, but it's been 
replaced with the content of the Harp part for this piece.  I don't 
know if you can glean anything from this file, but take a look and see 
if it tells you anything.

For comparison purposes, here is the most recent auto-saved version of 
the same file:

[attachment deleted]
Let me know if I can give you any other info that might help pin this 
down.

Cheers,
- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY
CC: of message I sent to Allen and MacSupport, minus the attached 
files:

Hi Allen, guys,
Allen, I know you're going to NAMM but hopefully you get a chance to 
look at this when you get back.

I think I may have an instance of the File Overwrite bug in action.  
This is in Fin2005a.  I have 22 documents open.  The frontmost 
document -- "08 The Gallows 2005.mus" -- is *displaying* the *content* 
of that file (a score), but when I go to print, the file that actually 
prints is a different (also currently open) file -- "WitCan - 002 
Percussion 2005.mus" ( a part).  I have confirmed this printing error 
twice.

I am sending you both files in their current states.  When you open 
"08 The Gallows 2005.mus," does it look like a score, or a part?  When 
you print it, does the printout match the screen contents, or does it 
print a percussion part instead?

UPDATE: when I open a second instance of the part, it prints 
correctly.  I'm going to save the problematic instance under a 
different name and see what happens.

- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

[Finale] File Overwrite Bug in Action

[Darcy James Argue]

CC: of message I sent to Allen and MacSupport, minus the attached files:
Hi Allen, guys,
Allen, I know you're going to NAMM but hopefully you get a chance to 
look at this when you get back.

I think I may have an instance of the File Overwrite bug in action.  
This is in Fin2005a.  I have 22 documents open.  The frontmost document 
-- "08 The Gallows 2005.mus" -- is *displaying* the *content* of that 
file (a score), but when I go to print, the file that actually prints 
is a different (also currently open) file -- "WitCan - 002 Percussion 
2005.mus" ( a part).  I have confirmed this printing error twice.

I am sending you both files in their current states.  When you open "08 
The Gallows 2005.mus," does it look like a score, or a part?  When you 
print it, does the printout match the screen contents, or does it print 
a percussion part instead?

UPDATE: when I open a second instance of the part, it prints correctly. 
 I'm going to save the problematic instance under a different name and 
see what happens.

- Darcy
-
[EMAIL PROTECTED]
Brooklyn, NY
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale