Closed internationils closed 6 months ago
I right-clicked on the file in the explorer, renamed it, and when it renamed, the editor window showed it as blank. My guess is that MM is too quick to load and Dropbox creates the filename with 0 bytes before the content shows up in it, and in that window, MM opens it. Can you maybe add some logging including filesize when renaming/opening files? That might help narrow down the issue.
Whats weird is that opening the file fro the explorer changes the explorer view of the subdirectory containing the file, and does not stay at the higher level I had earlier. Also, trying to open it several times (it showed the file with content on the 4th try or so) created multiple blank backup files...
Also, the first backup file on disk is not shown in the explorer view, the others are shown:
Deleting the backup files from disk immediately makes them disappear from the explorer window.
I also mis-renamed a file (typed a ":" instead of an underscore in the filename) and this happened:
This led to two versions of the file after fixing the typo... the old c40_think_ahead.md one with data (but not showing in the MM explorer), and the new one without data:
Pasting the text from the old file (from notepad++) into the new file and saving hard-froze MM.
I've also had a few freezes when ctrl-s ctrl-w saving and closing files rapidly. The program freezes completely and needs to be killed from the task manager. I haven't lost any data yet luckily, the saves or the baks where always there.
I've also noticed that when renaming files, the old tab closes (there's a brief flash to the title screen if it was the only file open), and then the new file opens empty. Thats when the original file still has data, and the bak has a zero filesize.
I can't duplicate any of this.
I think this may be related to your original Dropbox issue.
Dropbox - if it's working correctly - should store and manage files locally first before syncing in the background.
As said I have most of my files in DropBox too, some synced some not, but I've not seen this kind of issue.
I suspect you are right of the symptom, but I really think there's an issue with Dropbox and how it behaves on your end literally screwing up file integrity while files are being read.
FWIW there are a few changes in the way backup files are handled - they all get cleared now when you save. Previously the numbered files (if there's a left over) were never getting deleted. The filenames have also changed and start with ~
and end in .md.saved.bak
so they are all at the top of the directory stack and don't clutter then 'normal' view.
I'm going to close this because this is very likely unrelated to file renaming, but related in some way to opening files in general.
Just saw this again in .18 I renamed a file from something.md.txt to something.md, and the .md file opened blank. Looking in the directory shows a normal .md file and an empty .bak file (which seems strange al I had only renamed with a right-click (and not single clicked) and the tab was showing italics for read-only ?!?). Dropbox files as usual, but I am on a fast DSL network.
Can you please reopen this or open another bug where I can track additional findings?
Unless you can give me something repeatable, there's not much of a point...
Just updated to 3.2.21 this morning. Started it, clicked on a directory, then clicked on a file, and got a blank tab, but with the program frozen. I killed it after a few mins, nothing in the error log unfortunately. Is it possible to enable a debug mode that tracks file open / save / close events, and also tab creation / destruction events? Maybe that can help narrow it down.
So I tried something just to see what would happen. I created a new directory and threw one file into it. The directory as per another bug was created second to last, and the dir also had a subdirectory ".." thet, if clicked, takes me up two levels to the root of the dropbox. This dir should not be there. See below:
But anyway, I created a little script:
#!/bin/bash
COUNT=0
SOURCEFILE="test.md"
ORIGFILE="test_$COUNT.md"
cp $SOURCEFILE $ORIGFILE
while :
do
COUNT=$(( COUNT + 1 ))
NEXTFILE="test_$COUNT.md"
echo "mv $ORIGFILE $NEXTFILE"
mv $ORIGFILE $NEXTFILE
ORIGFILE=$NEXTFILE
sleep 2
done
Running it and clicking on file after file as the name changed worked fine. So it appears to be the renaming / opening from within MM that is the issue, not renaming externally.
Are all of these in DropBox? If so can you try folders outside of Dropbox and see if the issue repeats?
It looks to me you're hitting this constantly so if it's repeatable on dropbox, but not on local folder then we can at least pin this to DropBox being part of the problem.
Honestly to me this problem looks like it's related to the WebView. The hanging tab points to the WebView not loading the document or getting hung in the process of loading. MM loads content from files but the files are in your TEMP folder. Is it possible there's some issue in your temp folder? Like AV deleting files perhaps as they are being read or navigated to by the WebView?
Can you install the 3.3.1 (Preview Release) from the download page?
I tried something different here: I downgraded the WebView interface and runtime to an earlier version. I'm wondering if perhaps an older runtime might work better.
This is specific to 3.3.1... I'll probably roll back to the newer WV versions unless I hear that this is makign a difference for you.
Will do, can probably only test it next week though...
F2 to rename a file... then change the name and hit enter. Often it works, but sometimes the tab opens empty:
Closing it and then opening it gives that file plus a backup file, both showing empty:
Closing both of those and opening the original file again showed the contents. It feels like there is a desync between the rename-save-open-load_content operations. These files are on dropbox, so maybe some things aren't as instantaneous as expected?