"Score pathname" in "Score properties" not updated on "Save As..."

Relevant part of that disussion for a developer to look into this:
That dialog uses filePath->setText(score->importedFilePath());, but it seems "Save As" doesn't (re)set this (using setImportedFilePath()), only readScore() does, but none of the two saveAs() methods (of which one uses the other) does.

Snippet from readScore():

      QFileInfo info(name);
      QString suffix  = info.suffix().toLower();
      score->setName(info.completeBaseName());
      score->setImportedFilePath(name);

Adding these lines to one of the saveAs() methods should fix this issue

I would state my take on this differently. Even though sure, to some people, pathname info is not so important, I am not suggesting this has any relevance here. To me, it's the simple fact that there are two equally valuable pieces of info to know about an open file: where it was opened from and where it was last saved to. Right now we show the former but not the latter. So, I think the solution is that we add a new field to the dialog to show the latter. Then everyone should be happy.

So, no, I don't propose changing Save As at all. Just change the Score Properties code to display an extra field, not just importedFilePath() (which should not be changed, that would be a lie, it still was imported from that location save as or not) but also the current path.

.

@Marc: I disagree and am with @BSG here, it should show the current pathname and that only, just as it does when reopened.

I am fine with relabeling the display of the very useful pathname that is already displayed, so instead of saying just "File Path" is says "Original File Path", or "Opened From", or whatever. I'm also fine with adding a new field "Current file path" or whatever.

I'm not fine with getting rid of the valuable information that is already present just to replace it with other valuable information. Are people literally saying they want to get of a feature others find valuable, even though it's perfectly possible to have &both* and make everyone happy? If someone is literally saying that, then yes, you disagree with me. But I hope no one would wish to remove a feature others find valuable, just because you personally do not.

And I'm definitely opposed to having the internal importedFilePath() be messed with to not even make it possible to retrieve that information anymore. importedFilePath() needs to stay as is. There may be code today that relies on it, and even if not, there may be code tomorrow that would like to.

And no, I don't think anyone disagrees with what "current" means in this context, if we wished to clarify that this is what the proposed new piece of information would be labeled. Original versus current, seems clear enough to me.

That old information is not valuable at that time anymore, it is just plain wrong

How is it wrong? If you open a file from C:/Tmp, that fact remains true no matter how many times you do a save as to some other location.

Whether I use Save As or Save a Copy (and I do use both, each for its own purpose), it doesn't go back in time and change the fact that I literally opened it from Tmp. I like to know that info. Maybe you don't, and that's OK. But please don't argue for taking this info away from those who do value it. I'm not arguing against keeping you from having the info you want - I'm merely proposing we provide that useful info in addition to the useful info already present. Win-win. Why is there objection to everyone getting what they want? Seems a no-brainer to me.

The UI calls is pathname, but shows the imported file name instead, this is just plain wrong. Having 2 fields there is just completly useless, if you never use Save As

Imported pathnames are pathnames to, it’s not wrong, just poorly labeled.

True, in many cases the two paths are the same. We could choose to just show the one in those cases. Or show them both, as your OS and it’s tools show both created and modified dates even when they are the same.

Imported pathname is the name of the method, but IMHO a misnomer (the label in that dialog is not a misnomer though), and a pretty useless information if it isn't kept across close/reopen. And if it'd be kept and stored into the score, it got to be a list, not just a single entry

"Imported" is indeed a misnomer for files that were opened normally. But as for keeping across close / reopen, that to me defeats the purpose of knowing where it was actually opened from during this session. After all, who knows how many additional save as operations may have been done, how many times the file might have been moved using my file browser since it was last saved, or indeed if I ever saved it at all or if the file came from another system. I might want to know what folder I opened it from during this session, but if it's something I downloaded from musescore.com, I surely don't care what folder the person who uploaded it to have last saved it in on his system.

The behavior across "continue last session" is a different matter, I don't use it, so I don't have a good feel for how that should work. But, probably would be best if, after crash recovery, autosave save files lied and just said they were opened from where they were opened from during the previous session.

After a "Save As" it is irrelevant where it got opened from, that file might even have been removed meanwhile.
Keeping the history is not worth it IMHO, but if we're keeping last (and add current), then we should keep 2nd to last too, etc.

I don't think it is, but it seems the usefullness of additionally keeping the "imported from" is controversial.

Right. To be clear, I absolutely positively 100% agree, no reservations whatsoever, agree that the "last saved to" folder is interesting information.

I also get that not everyone sees the use of also knowing "opened from". I do get that, due to the different workflows employed by different people, it might in fact not be useful to some people. But I would just ask those for whom it is not useful would not try to tell others that because they don't use it, no one else should be permitted to have it either.

Because if that were the standard, I'd be going around trying to remove features I don't happen to use, like, say, figured bass, or the ability to enter notes by mouse :-)

No need to try convincing me ;-) it should show the correct current pathname.
The controvery is about whether (and why) it should also show the previous one, and if so, whether (and how) to do this accross sessoins and possibly even collect all previous ones. And here I'm against this al, I see no use for any of this, but esp, nit just shoing both in the current session.

Hmm... maybe... how about about showing both in the same field? Like "path/to/current.mscz (formerly path/to/previois.mscz" with the 2nd part only shown after a "Save as"?
That's be something I could live with

Works for me except I’d be concerned about it getting to long (edit, fixed autocorrect weirdness). Separate line items seems more likely to format well.

But to be clear, definitely do not attempt to preserve across sessions in general. Only perhaps when using “continue last session”.

I'm using "Continue with last session" since ages, basically ever since MuseScore 0.9.5 ;-)

I don't consider "continue last session" an anomaly at all, not sure where you got that idea. It's just an option I don't happen to use myself, so I won't pretend to guess what users who do use it might prefer. My guess is what is most natural would be to have it still remember where it had been opened from in the previous session, even though during the new session it's actually opening from the "new" location I assume. But I'm fine with whatever others who actually use that feature (and who do care about "opened from") prefer. Maybe that intersection - people who use "continue last session", and "people who care where a file was opened from" is close enough to zero that we don't need to worry too much how we handle that case?

That information would pretty surely be lost, as the scores all got closed with the session and reopened with the next.
To me another reason not to show that old path at all ;-)

Unless it was saved as part of the session file, I've never actually looked at what's in there. But I'm personally fine with just doing whatever is most convenient to implement for the "continue last session" case.

I haven't check either, but I'm pretty sure the previous path is not saved in the session file.

Or it doesn't save the current path in the session file, and just opens the previous, which would be a pretty bad bug then.
Edit: tested, no such bug (PHEW!!)
And checked session file too: no record of prev path

I definitely have more of a vested interested in what happens after a crash than when using the "continue last session" option, since even though I don't use the latter option, I do recover from crashes as often as anyone. More than most probably, since I'm constantly trying to reproduce crashes reported by others as part of the development process.

So, in the case of recovering after a crash, we know the actual opened-from location for the new session is the autosave file. But of course, we also have a right to expect that further saves will go to the "normal" location. And obviously we are all interested in knowing that "normal" location. So clearly, showing the "normal" location as the "current path" in Score Properties has value to all.

But maybe this is a case where even skeptics might agree it could potentially be useful to know the opened-from location is not the "normal" location. Because the two versions of the file are likely to be different, and knowing which is actually open at the moment could be quite useful to anyone, not just me. But even if others don't see this how it might ever be useful to them, I can absolutely assure you I'd find it useful.

To be honest, I never trust this information right now, because I've never given a moment's thought to how it is managed and have no idea what it is showing me. But to me it would be a fantastic improvement to have some confidence that both those two pieces of information - opened-from, and saved-to - are accurate and reliable.

So this tells me that at least for the crash case, opened-from needs to be honest and actually tell me it was opened from the autosave if that is in fact where it was opened from. I have less insight into what I'd expect if I then closed and restarted MuseScore with "continue last session" active. I assume (because I am too lazy to force a crash in order to test!) that the recovered file is marked as dirty, so that on closing MuseScore, you'd be prompted to save the file, so then the "normal" location would be up to date. And I'd then expect the continued session on restart to load the "normal" location, and Score Properties to accurately reflect that.

And the same if there was no crash, but I had opened a score, done a save as, then closed and restarted MuseScore. At the moment of the save as, the opened-from and saved-to locations differ, and I'm very happy to have both shown accurately in Score Properties. After restart, with continue last session, I certainly expect the newly saved-as version to be the one loaded (sounds like it is), and at that point, I expect opened-from and saved-to to both point to that location, with the version I was working on before the save as during the previous session no longer showing anywhere except as a "recent file".

This seems a different issue all together and no way we fix this issue (or not at all) is going to change how recovery after crash is working. The original path is either gone (seen that happening) and you'd end up with that scXXX.mscz and need to find out where it should go (via browse and Save As), or the one from the session file is taken, which is, as I just checked, the correct one (unless the crash happens on the Save As, I guess).

I'm not suggesting we change anything about how crash recovery actually works - as far as I know, it works well these days (certainly compared to the old days when you needed to do an explicit save as to avoid having your score end up in the Windows Virtual Store!). I'm just suggesting that this particular workflow is one common to almost everyone, so it's worth considering how Score Properties reports information about what is going on.

To summarize, crash recovery to me is the single clearest use case to demonstrate why knowing both the "opened from" and "saved to" locations are useful. I want to know the file I am looking at right now was opened from the autosave, not the normal location, and I also want to know that when I do save it, it will go to the normal location. The way to assure the user of that is have "opened from" point to the autosave, "current" point to the "normal" location. Both pieces of information should already be available internally as far as I know, so it should be a trivial change to make the dialog present them both clearly. And then I would claim it's also useful to at least some of us to have both pieces of info available in the non-crash-recovery case too.

So in the crash recovery case show the current scXXXXX.mscz and the "previous" real pathname? Or vice versa?
In the new session case that info is lost, no way to get to it anymore

I am saying be literal. Whichever location we actually opened the score from during the current session, show that as "opened from". Whatever folder we plan to actually save to when you press Save, show that as "current" (or however we label these).

So, after crash recovery, "opened from" is the autosave, "current" is the normal location. After a clean restart, these are always the same until you do save as. That's true even after a restart with continue last sessions. Be literal. If we opened the file from location X during this session, present X, even if that same score had been opened from a different location during the previous session.

As far as I can tell, that should require no special casing, no requiring any info not already available in the code. Just use importedFilePath() for "opened from", fileinfo() (I guess) to get the info about the "current" path. My sense is this does exactly what I expect in all cases. And sure, we could suppress display of "opened from" unless it different from "current".

That's my understanding from the start

Mine too.

I have a solution almost ready, no change in output if "Save As" has not been used yet, but 3 lines it it has, the real current filename. a text "initialy opened from:" and the previous filename.

PR to follow shortly, need to some testing, like when using score with parts.

New (never saved) scores, show empty, as before, after autosave, forced crash and recover it shows a not yet existing filename starting with the install dir of MuseScore (so here's room for improvement, not sure though how to deal with this), and ending with the score title (without mscz) and 'initially read from' the autosave path. Once saved It shows the real saved to path and the imported from, so exactly as intended

Open unmodified or modified shows the same as before, one line with the current path. Same after autosave and forced crash if unmodfied, with modifications autosave, forced crash and recover it shoes the filenam it would save to and the autosave one as 'initially read from, seems good to me

It works properly on scores with parts and on their part tabs (shows empty there)

Freudian slip I guess (corrected now)

Sample image, after a Save as:

See https://github.com/musescore/MuseScore/pull/5727

Still unsure how or whether to deal with that one scenario:
New (never saved) score after autosave, (forced) crash and recover shows a not yet existing filename starting with the install dir of MuseScore, and ending with the score title (without mscz)

Well, good idea, could have been mine ;-)
But how to detect?
Hmm maybe use the missing extension as the sentinel?

Hmm, probably better, if (!score->masterScore()->fileInfo()->exists()) // crash recovered before 1st save

Pushed such an addition, along with building artifacts, so please test those

Fixed in branch master, commit fe182f715a

_Fix #301124: Always show correct pathname in Score Properties

even after a "Save as", then also show where the file initialy got read
from_

Fixed in branch master, commit 4ccc740c65

_Merge pull request #5727 from Jojo-Schmitz/metaedit

Fix #301124: Always show correct pathname in Score Properties_

Automatically closed -- issue fixed for 2 weeks with no activity.