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

• Feb 14, 2020 - 13:15
Reported version
3.4
Type
Functional
Frequency
Once
Severity
S5 - Suggestion
Reproducibility
Always
Status
PR created
Regression
No
Workaround
No
Project

Saving a file to a different pathname does not update the pathname as reported in "Score Properties". There is debate about whether the current behavior (displaying pathname it was loaded from) is more useful. While many people feel that "current pathname" is something that changes when a Save As is successfully performed, and full file pathname is a very fundamental attribute of a file, others feel that in recent years, it has declined in visibility and importance in modern UX's. See the (first) linked page for such debate.


Comments

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

Severity S3 - Major S5 - Suggestion

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.

Feb 14, 2020 - 17:03

In reply to by Marc Sabatella

It doesn't say "Imported file path" or "immediate internal file source". It says "file path", and after it's been written somewhere else, and the original place it was loaded from is therefore out of date, it is false.

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.

Feb 14, 2020 - 19:49

In reply to by Marc Sabatella

There is a difference between "Save As" and "Save Copy". "Save As" means that the file now lives in the new place. "Save Copy" means it doesn't. When you "Save As", it is no longer in C:/Tmp -- an obsolete copy is there. What is your understanding of the difference? Do you really believe in "Save As"?

Feb 14, 2020 - 21:05

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.

Feb 14, 2020 - 21:12

In reply to by Marc Sabatella

Fine; don't take it away if you like it. Just give me the current pathname along side it and make the distinction clear. For what it's worth, I have never, ever, in any application on any of the many operating systems I have worked, wanted to know the "original" pathname of a file once I had written it to somewhere else, but if there are people to whom that is important, who am I to disenfranchise them ...

Feb 14, 2020 - 22:33

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

Feb 14, 2020 - 23:21

In reply to by Jojo-Schmitz

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.

Feb 15, 2020 - 07:38

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.

Feb 15, 2020 - 15:27

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.

In reply to by Jojo-Schmitz

Where in my file system I first read it from can be interesting. If it is not in the same app session, it gets complicated (e.g., an .mscz emailed to me). In no case is sca02345 interesting unless tracking down a bug. If we really all agree that the current, correct, this-file-system, this-session pathname is the most useful and not (you claim) controversial, shouldn't it display that?

Feb 15, 2020 - 16:08

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

Feb 15, 2020 - 16:11

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

Feb 15, 2020 - 16:48

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.

Feb 15, 2020 - 17:03

You seem to consider "continue last session" an anomaly. I do not want crashes or needs to shutdown (the app, or any interactive app, or the system), including installing new versions, to clear my workspace. I don't know why anyone would; anyone can clear their workspace/start afresh at will. I have MuseScore open 24/7. Each morning I want to continue working on what I was working on the previous night. Browsers and editors the same. "Continue last session" seems hardly the anomaly you portray it as.

20 or 30 years ago, you would shut down the computer when you were finished using it for a while, to save electricity, disks, fans, etc. Those days are long gone. Apps should stay up 24/7, and recover when shut down or crashed.

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?

Feb 15, 2020 - 17:31

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

Feb 15, 2020 - 17:36

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.

Feb 15, 2020 - 17:38

If, when MuseScore starts up to recover, scores were last auto-saved, not real-saved, that must have been due to a crash. If they are successfully recovered from the auto-save, I don't really care what the autosave file was; I want to know the real, actual, permanent pathname of the file, and it should be marked as "modified", i.e., needs real saving, or discarding, upon reopening. Recovery means recovering the state, including key facts like the correct, real, expected pathnames of the currently open documents. If you close MuseScore purposefully, you have to answer a "save or discard" question about every open document; there should be no "false pathnames", and when you reopen it, it must recover from the real, actual, permanent pathnames from the last Save or SaveAs of each erstwhile open document.

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.

Feb 15, 2020 - 18:49

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

Feb 15, 2020 - 19:15

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

Feb 16, 2020 - 12:30

Here's a notion we haven't discussed. There is a place where the file will be written when you click "save", not "save as", not "save copy". That is the "real pathname" and deserves the maximum visibility.

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.

Please test through crashes (force-terminate process by godlike means), with both new, open unmodified, and open modified buffers.

Feb 17, 2020 - 18:00

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)

Feb 17, 2020 - 18:14

Freudian slip I guess (corrected now)

Feb 17, 2020 - 18:20

Das iz goot, tu.

Feb 17, 2020 - 19:01
Status PR created active

Lux gød!

Feb 17, 2020 - 20:57

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)

Feb 17, 2020 - 20:59

A bold notation never saved ?

Feb 17, 2020 - 21:01

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