Not showing original file content when it has backup files

[internationils]

I am facing https://www.dropboxforum.com/t5/Create-upload-and-share/iPad-mdwriter-app-created-multiple-file-copies-when-Dropbox-was/m-p/762602 with dropbox when it can't sync due to blocked ports. This leads MM (or is dropbox doing it?) to create backup files in some cases.

When opening a file that has a backup (or sometimes 2 or 3 backups (with .backup and sometimes some strange letters also contained- possibly from Dropbox?!?) the original file does not show content initially. When opening it another time it does show content. Not all backups that open are always shown in the file browser on the left.

To reproduce: work in dropbox. Block a dropbox port or two, leaving dropbox in a permanently "connecting" state. Work on some files. Close MM, reopen it. You should then have the situation I see.

Update: MM is freezing when CTRL-S CTRL-W closing files, after the CTRL-W. The text window is empty, the canvas gone, the tab is still there. It becomes completely unresponsive and I have to task-manager kill it. This is with Dropbox showing online and up-to-date.

[RickStrahl]

If the file is on disk and is accessible but in some inconsistent state, I can't really detect that and I don't think there's anything I can do about that. If files are in an inconsistent state due to Dropbox, then that's really a Dropbox issue. DB shouldn't be making partially published files available but should temporary copy the files then rename/move to replace the existing file when the transfer has completed, as most solutions do.

A save operation should save local first before Dropbox syncs, so that should have no impact any actual file operation. I've seen situations where DB can't write files because they are locked, because they are in mid-sync (I think that gets a file access denied error from windows) but that should fail immediately.

FWIW, I store all my MM files on Dropbox, so I work in Dropbox all day long every day, and I've never had an issue even with dropped connections so I'm not sure what's going on in your situation that's causing this inconsistent file state.

Backup files yes I've seen that, but never files that don't load or have partial content.

[internationils]

I'm not sure it is in an inconsistent state. I've repeatedly clicked it, and the original non backup file got loaded twice, once showing content, the other time just showing the tab and no content window below it. Can you maybe check a filesize and throw an error dialog if zero? The filesize definitely is not zero as the second tab had that same file loaded correctly. Any other checks that you could do for a non-successful loading of a file? Unfortunately I didn't screenshot it when I had that result, and I won't be back in that corporate network for a while, so no way to reproduce it, sorry...

[RickStrahl]

Based on what you've described it sounds like DropBox is screwing with the file consistency (the issue you pointed at and your experience). That points to inconsistent file state with the file basically being written to by DB while you're trying to read/write it at the same time.

I can't duplicate that even with 'blocking dropbox ports'- I've never seen anything like this nor have I heard about a case where that happens. Not saying it doesn't happen but I can't duplicate it.

If you're seeing files that have garbage in them that points at DropBox screwing with files in some way that probably isn't intended. Again I can't corroborate that, but if there's something screwy going on with files being written while they are being read I can very well see that there will be a problem. In theory that shouldn't happen - DropBox should never write to an open file - it should be writing temporary files and then swap in updated files unless there's a conflict in which case it'll create versioned files.

As far as MM goes it reads files as a whole through top level functionality. If there's a problem as far as Windows is concerned, it will fail the entire read/write sequence and throw an error. It doesn't sound that you are not seeing that (check the status bar when this happens) and if it does show an error it should also show up in the error log file (Help | Error Log).

When you get the empty tab - is the tab actually loaded with an editor instance and just no text, or is it completely blank (ie. no input)? The latter is bad and usually points at a WebView crash, but that is likely a different issue altogether.

[RickStrahl]

I also think the backup file has nothing to do with this issue - that's probably just a coincidence. MM doesn't do anything with the backup file, except delete it when the file is saved or closed.

[RickStrahl]

As for Ctrl-S/Ctrl-W make sure you have the latest version. There was a fix recently that fixed lockups when closing windows.

[internationils]

This was with

[internationils]

I wonder if this is due to slow connections. I've had this when on guest wifis that are not bad but sometimes a little slow and drop every now and then. I wonder if DB is syncing something and it just takes longer, and MM relies on the operations to be essentially atomic. Just downloaded 3.2.17.2

[RickStrahl]

In theory DB shouldn't be 'streaming' files in. If it does the files should be locked and inaccessible while that's happening. You can't have files that are being updated without locking and not expect problems because Windows will read the file based on the information it has available.

From what I have observed with DB when I have offline files or files that are being updated is that the file can't be written to while it's being updated. You can read it but you get the 'old' original version. The file is updated after the transfer's complete. From what I can see DB copies temp files and them moves them into place effectively replacing the original file which guarantees that the file is in a stable state.

This is how this should work but maybe there's something wrong with this process.

I do - on very, very rare occasions - also see the problem of tab content gone missing but in all cases this occurs for me it's because the WebView has crashed, and basically all instances of the WebView are frozen and inoperable and most likely MM will then also crash. In my case this usually occurs if MM is open for a really long time, and usually after coming back from a sleep or hibernate. Again very rare but it happens.

I guess the question I have is whether what you see matches that.

• Do you see WebView crash notices in the error file (Help | Show Error Log)
• When tab content goes missing is the app still working? (ie. can you go to another tab and it works? Back to the original tab and it then works?)

Or do all WebViews lock and MM basically beomces non-responsive.

[internationils]

I'll post them when I get them... I guess the logs from yesterday are gone, I got the one below today when experimenting with the right clicking on a file multiple times after it opened when the context menu was already open. And after right-clicking the file a few times the FB jumped back to the previous directory where I had the last file open (with no files open in the tabs). When the tab content goes missing, most of the time I can close and reopen the tab (sometimes empty the 2nd and 3rd time), but eventually get the content showing. I can go to another tab and work without problem, but I never do because I'm afraid to kill my file. Sometimes I get the crash, also sometimes when closing the last open file.

09.05.2024 09:42:37 - Task: Object reference not set to an instance of an object.
Object reference not set to an instance of an object.
Markdown Monster v3.2.17.2
10.0.22621.1.amd64fre.ni_release.220506-1250 - en-US - NET .NET 8.0.4 - 64 bit
LENOVO 20XWCTO1WW, Intel(R) Iris(R) Xe Graphics, hw-acc: True
WebView: rt: 124.0.2478.80 - sdk: 1.0.2365.46
de-DE - en-US
C:\Program Files\Markdown Monster
Portable: False
---
MarkdownMonster
   at MarkdownMonster.Windows.FolderBrowerSidebar.<>c__DisplayClass63_0.<<TreeViewItem_PreviewMouseDownClick>b__0>d.MoveNext() in D:\projects\MarkdownMonsterCode\markdownmonster\Windows\FolderBrowserSidebar\FolderBrowerSidebar.xaml.cs:line 1165
System.NullReferenceException
---------------------------

[internationils]

Your comment on the MouseUp in the other issue got me thinking, could it be that there are several left-click mouse events conflicting and that that is leading to parallel operations and causing the problem?

Quick test: create a directory with 10 files or so. Click around a lot. Sometimes you will double click (getting into write mode), but sometimes you will have a file open in read-only mode and the next click will open another one in read-only as well without closing the previous one. So this is "debugging by click-spamming" : )

[RickStrahl]

Yes. As I mentioned in another method, there's been several fixes in relation to this in recent updates.

I'm going to close this, as this issue is likely unrelated to the backup files, but more specifically related to the folder browser.

If it continues lets see if we can narrow this down better.