Data loss on Rename

[rngbus]

Edit a markdown file but do not save. Select Rename in the file and folder browser and rename the markdown file. Markdown Monster will prompt you to save your changes, select Yes. Notice that the file is renamed, and the changes are lost.

Expected result: file should be renamed, and the changes saved

[RickStrahl]

I took a quick look just now and not seeing what you see, although I do see some funky behavior.

• Create a new document and save it
• Make sure file is visible in the folder browser (arrow or file sync)
• Now type some more text
• Go to folder browser and rename
• File asks to save, so say yes (original file now should have changes)
• Rename occurs
• New file is now open in editor with original text and new filename
• New file also exists on disk.

This is all as it should be...

But what I see is that the original file remains which is not correct.

This doesn't sound what you're describing - can you walk me through your scenario, if different?

I suspect this might be a timing bug due to async changes a while back. I'll take a closer look at the code tomorrow to see why the file is not actually deleting.

[rngbus]

I could send a video if it helps. I followed your steps and saw the same data loss issue. I do also see that the old file is still there on disk, and does have the changes saved there. I've tried rebooting and nothing changed. Should note I'm running 2.7.4 on Windows 10 with a fast SSD. Definitely could see some timing issue causing both outcomes, especially if you are relying on a file copy to do the rename. Perhaps you are doing an async write followed by a copy, and the copy happens before the write?

[RickStrahl]

Took a look at the code and sure enough the code wasn't properly updated when the async transition was made - what worked sync didn't work async anymore as timing issues with background file operations where wreaking havoc files not being completely moved around yet. The fix was to rearrange the operations to make the close operation happen much sooner and adding an additional idle state to allow the file IO to catch up.

In my testing with small and largish (20k) files I no longer see any issues but give this a shot with 2.7.4.2 pre-release or later (from the download page).

The code fix was to explicitly wait after the close operation and add the extra (nasty looking dispatcher call) wait state:

if (File.Exists(fileItem.FullPath))
{
    // If tab was open - close it 
    tab = Window.GetTabFromFilename(oldFile);
    if (tab != null)
    {
        await Window.CloseTab(oldFile);
        await Dispatcher.Yield(DispatcherPriority.ApplicationIdle);
    }
    
    if (!File.Exists(newPath))
        File.Move(fileItem.FullPath, newPath);
    else
        File.Copy(fileItem.FullPath, newPath, true);

    await Dispatcher.Yield(DispatcherPriority.ApplicationIdle);
}

It wouldn't work correctly without the Dispatcher call in place.

[rngbus]

Great, tested the pre-release version and it seems fixed. Thanks!