I saved edits manually to text file shared from Telegram, but the file didn't retain the updates.

[mjlcourier]

I recently lost data on a file after a long editing session in Markor version 2.13.1 on a .txt file I had shared to myself from another device using Telegram.

As I worked, I repeatedly pressed the [save] icon at top right of the edit view, and received haptic feedback showing that the command was understood by the app. I took no notice of the default save folder to which I assume saves were being made. I was unaware of Markor's autosave function.

At the end of the session I struggled to transfer the file from my Android phone, a Google Pixel 8, because of the unfamiliar file structure Android uses. I swiped horizontally away from the Markor app to look for suitable file viewing app. Not finding it immediately, I tried to save my work from within Markor as a .txt file under a new name. This I intended as a safeguard against losing my data. Markor gave no feedback suggesting that the save operation was not successful.

Although I eventually found the nearest equivalent on Android to a file manager or file explorer deep in its Settings list, when I returned again to Markor by swiping I could not see the content of my text file.

When I searched through Markor's own file search tools for that material, Markor reported that there was nothing to view corresponding to the date and time of work in its default save location. Neither was anything corresponding to this session's work visibly saved to the folder under Telegram's location on Android, where files are received from my self-transfers in Telegram.

I eventually located the original .txt file I sent to myself in a Telegram folder, but it showed no sign of the long editing session I put in while using Markor on the same day at a later time.

The behaviour of Markor in this instance defies the expected functioning of both manual and automatic saves in the app. Is there some sense in which an app 'closes' on horizontal swipe? If yes, this also breaks expectations of the swipe function in Android as I understand it. Are automatic saves placing data in a location I do not expect?

I tried to replicate the behaviour with a short text document sent to my phone from Telegram. I can now confirm that a tiny error message is triggered at the bottom of the display when I attempt to save changes to this document within Markor: "Error: Could not open file." I am none the wiser because the file is visibly open in Markor when the attempt to save manually triggers this error message. It is unclear to me what would stop Markor from saving my edits to the default location which is a Markor folder.

Your advice is much appreciated. Searches have not revealed closely similar problems to mine. The work I did on the text file remains missing despite searches for the edited text by content string across the phone's data folders.

[harshad1]

@gsantner I think one solution to these types of issues is to refuse to open text files which can't be written to. IMO it is better to force users to save files locally rather than loose data

[mjlcourier]

Agreed. It is counter to expected behaviour that a file that cannot be written to announces its status as 'cannot be opened'. The confusion is worse if that file appears to have been opened and accepts edits. I would have saved locally had I been prompted to do so. I was really baffled by the apparent failure to save material that appeared open and editable to a local folder under another name.

[clach04]

I think opening the file to read/view is reasonable (#2474 (comment) specifically mentions viewing), but blocking read/view would be a pain. If the file is read-only one option to consider would be to disallow editing and keep it in view mode (with a clear message if an attempt to switch to edit mode is requested). I'm not clear if Markor knows this when it opens the file though so I've no idea if this is feasible.

[gsantner]

Setting EditText to non-editable, and disable writing is a option that can be implemented.
See binary format handling (jpg/mp3) for reference.