[Core]: After deleting open file's parent folder, cannot Save changes and Save As shows incorrect error message

[julieyuan]

Steps:

1. Edit two files with same name under different folders and don't save the files.
2. Delete one folder which contains one of the two files.
3. Click Delete button on the Confirm Delete dialog.
4. On the pop up dialog File Deleted, click the button Keep Changes in Editor.
5. On the working Files area, right click the file which's folder is deleted, and save it.
6. After step4, on the working Files area, right click the file which's folder is deleted, and choose save as.

Result:
At step5, it will pop up Error saving file and can not save the file.
At step6, after you save as the file to another name, it will pop up two dialog. First dialog is Error opening file dialog, second one is External Changes dialog.

Expected:
It should can save the file, at least should save as the file without error message.

ENV: MAC10.8 English OS
Build: 0.29.0-8678

Snapshots:
Please refer to snapshots for details:
Step2:

After Step4:

After Step5:

After Step6:

[njx]

To @redmunds. Marking low priority given how unlikely the scenario is, but could raise the priority if it seems like there's a more general issue.

[peterflynn]

Copying over some thoughts from PR #5614...

I wonder what the right user experience is. What do other editors do here? It seems like there are at least three options:

1. Leave editors open if they have unsaved changes (close the rest). When you switch to those editors, pop up the existing delete-vs-unsaved conflict dialog.
2. If any applicable editors have unsaved changes, roll those filenames into the folder-delete confirmation dialog. In other words, the choices are agree to lose all those unsved changes or cancel deleting the folder. Thus no editors with unsaved changes can be left open after the folder was been deleted by Brackets. (This is similar to our atomic bulk confirmation dialog on quit).
3. Automatically turn such editors into untitled documents. (This seems a little odd to me but I could swear I've seen Sublime do this in some cases... so it seemed worth including).

[redmunds]

I like solution 3 (as I also stated in pull request #5614).

[redmunds]

I just added more comments to pull request #5614, so be sure to read both threads!

[peterflynn]

There's a forum thread suggesting that landing file-watchers will reduce the impact of this bug slightly: the file is correctly saved when you choose Save As, but you still see the two spurious error dialogs.

[peterflynn]

Amending description & title (was "[Core][Keep changes in Editor]: Can not save or save as a file which is deleted from File tree but be kept in Editor.") to reflect the bug more clearly. The title didn't make it clear that this only happens when deleting folders, and the behavior has also improved slightly.

[peterflynn]

Now that #6744 has landed, I wonder if the simplest solution here would be to just make sure the Save and Save As operations work correctly. (Save would need to recreate the parent folder chain as needed, so maybe we shouldn't fix that case and instead just make it give a clearer error message; but Save As seems like it shouldn't be hard to fix).

The original options 1-3 above are all slightly nicer UI-wise, but they all seem more complex to implement as well.

[peterflynn]

Nominating for 1.0

[peterflynn]

Note: In dupe #7594, @pthiess reports that if you quit Brackets while in this state (and choose not to save changes), when you reopen Brackets and it tries to restore the working set you'll get another error dialog when it tries to load the now-nonexistent file.

[peterflynn]

See also #8610, which is about the lesser (but still slightly confusing) issues that arise when deleting the file itself (not its containing folder). If we do something here we might want to extend it to cover that case too.

[redmunds]

I tried this again (since it has Brackets 1.0 Milestone). I do not see the "External Changes dialog" as stated in the Results section. The file is being saved (with "Save As", not "Save") as stated in the Expected section. So, is this now Fixed?

I think the "Save" command in step 5 should behave the same as the "Save As" in step 6. Is that functionality captured somewhere else?

[peterflynn]

Reviewed -- keeping in as low priority / opportunistic for 1.0.

New plan for the simplest possible behavior:

• Make sure Save As works (@redmunds thinks it does already)
• In Save, check if the parent folder exists, and if not just invoke Save As instead