Ok, I'll try to reproduce the problem. I'm glad you catched the issue before it caused damage. 

Could you please send me a copy of the smb.conf file (or just the relevant parts of it) so I'm using the same settings?

Hmm, interesting, does Samba/SMB even support symbolic links (since it is a Windows protocol)?

What happens when you try to edit the same file using Apple's TextEdit? It uses the same NSDocument architecture provided by Apple's Cocoa framework that is also used by Textastic.

TextEdit and Xcode both use autosaving by default on a fresh installation of macOS, but you can configure it in System Preferences to also ask whether to save your changes or revert to the last explicit save when closing a file.

On iOS, autosave is absolutely the default - there is no explicit save command in Notes or Pages for example.

I do of course understand where you are coming from and why the ability to disable autosave would be useful, I was just responding to the claim that this was "non-standard" behaviour.

It is absolutely the standard on iOS and macOS and even required if you are editing files stored in iCloud or in the Files app so that multiple apps can edit the same file using file coordination.

Hmm, I just noticed that this is in the "Textastic for Mac" forum which doesn't have an SFTP client.

Are you having this issue on a Mac or on iOS? Is this when opening a local symbolic link on Mac?

Hello,

thanks for letting me know about this issue.

It should work if you download, edit and upload the file that the symbolic link links to.

Textastic should probably at least warn you when you are trying to upload to a symbolic link.

Can you please tell me which other editors handle this properly?

It could be related to the VPN connection. Can you connect to a server on a local network and check if you are seeing the same problem? Of course I understand if that is not possible.

The new version 9.5.1 includes the bug fix and should be available on the App Store now.

Please let me know if this does indeed fix the problem.

I found the problem: Textastic's web preview view controller and the contained WKWebView instance was never freed and continued to run in the background because of a retain cycle:

The preview view controller registered itself as a JavaScript message handler for the web view to handle console log calls. Apparently WebKit creates a strong reference to script message handlers, so when the preview was closed, the preview view controller and, as a consequence, the web view was in fact never released and JavaScript continued to run in the background.

I fixed this retain cycle now, so that the all web view resources and script handlers are freed when tapping the Done button.

I'll prepare a new release.

Thanks for reminding me. I'll try finding out more this week.