Saved-file pathnames: an odd behavior observed
In 3.4.2, Mac Catalina
I generally accumulate open files without limit, purging only when I get bored of it. My current MuseScore instance has files that have been there since several app shutdown-startup cycles, including the 3.4.2 installation. I noticed that all of them had "....Library/MuseScore3/.....sca12345" temporary pathnames listed in "Score Properties".
I didn't believe it. I made a small change to one of them, and saved it. The pathname did not change. I then closed the file. I then opened "the real file" from the command line, and found my change included!
Someone's not telling the truth.
Comments
I'm having trouble understanding what you mean by "accumulate open files", "purging", "current MsueScore instance", etc. Are you talking about the list of files in File / Open Recent?
I do think I know what you mean about the pathname not being updated. I'm not sure how to reproduce that offhand, but I think I've seen something like it before.
In reply to I'm having trouble… by Marc Sabatella
By "accumulate", I mean that I open a lot more files than I close; I generally review a lot of "student" work, try variations of posted scores, and after weeks I have dozens of open files. This is my behavior pattern as a user, not a feature or misfeature of the app.
By "purge", I mean "I start looking through my open tabs and deliberately close things just to reduce the number of open scores/tabs", in spite of the lack of a way of listing them all (hint).
The list of files in "Open Recent" is almost never, ever, ever right on my Mac; it is almost always empty, or has 2 or 3 files recently closed. It is as good as useless (it seems highly dysfunctional; I don't know why others don't observe this).
Of course, if someone does as I do, and keeps dozens of files open, "Recent files" isn't needed much.
By "current musescore instance" -- I don't know how to phrase that otherwise. When I launch the app, it creates an instance with which I interact. If I close the app, that instance is destroyed. The instance is the abstraction possessing processes, threads, memory pages, windows, and UI. I cannot have more than one open instance (unlike some other apps) because MuseScore (happily) checks. I am using the term "instance" as it is used in object-oriented programming, i.e., the product of instantiation.
In reply to By "accumulate", I mean that… by [DELETED] 1831606
So if by accumulating open files, you mean the actual tabs for open scores being displayed with the running problem, I don't understand how that list could continue to grow "since several app shutdown-startup cycles, including the 3.4.2 installation". Doesn't each such shutdown cycle start over with an empty tab bar? Unless, I suppose, you have it set to always "Continue last session"? That's what confused me.
The recent file list is supposed to be the list of actually opened files, it won't count newly created scores or even imports. I've been caught by surprise on that count before. But as far as I can tell it should be accurate within that definition.
In reply to So if by accumulating open… by Marc Sabatella
Yes, I always, always use "continue last session." That model is part of who I am, I guess. No, I never see opened-not-created scores (at least the right number of them) in "Recent Files". The Recent Files misbehavior is minor compared to the Score Properties not reporting the permanent pathname.
In reply to By "accumulate", I mean that… by [DELETED] 1831606
This usage pattern derives from many decades of experience with Emacs, and now browsers -- it's very hard to determine when you reach the point that you're truly through with anything -- (in the old days) library book, editor buffer, score or browser tab --- but (other than the lack of a "list buffers" equivalent), there's nothing about the app which makes this behavior difficult, except perhaps not being able to accurately determine the pathname associated with a given tab (which is what I'm reporting).
In reply to This usage pattern derives… by [DELETED] 1831606
Is it possible a crash (two of which I had -- they involved putting text in nested non-text frames) can put the pathname/recovery system into a state where this happens?
In reply to This usage pattern derives… by [DELETED] 1831606
Got it, so you are using "Continue last session", then? Still trying to wrap my head around what you are describing.
So, you have a currently-open tab representing a file that you perhaps actually opens weeks ago, now you are clicking that tab and using Score Properties to tell you the location of the file, but it's telling you about the autosave file the file might have originally been opened from? And then upon saving the file, it saved to the real location, and opening from that real location showed the change you saved, but Score Properties still shows the autosave path?
That's indeed the sort of thing I think I've seen happen before, so yes it does seem somehow the crash recovery process isn't managing this properly.
In reply to Got it, so you are using … by Marc Sabatella
That is precisely it, doctor (except "autosave file .... originally"). If it's "autosave", it can't be "originally". And since I closed it in order to do the test, there is no autosave file involved when I reopen it.
In reply to That is precisely it, doctor. by [DELETED] 1831606
Good point, it wasn't "originally" autosave, but the last time you ever took any explicit action regarding that file was presumably when you answered "yes" to the offer to restore your previous session after a crash.
In reply to Good point, it wasn't … by Marc Sabatella
At any rate, seeing the autosave pathname made me think that it had forgotten the pathname of my file(s), which would be a disaster. It hadn't, but I had no way of knowing that other than to run that test. Someone else might be terrified and forget to feed their cat or worse...