NetBox crashes when open office (MS Word) file from SFTP connection for second time

[blacklion]

Far Manager version

3.0.6453.0 x64 (b7d5b63)

OS version

10.0.26100

Other software

MS Word 2021

Server: FreeBSD 13.5-STABLE, OpenSSH_9.9p2, OpenSSL 1.1.1w

Steps to reproduce

1. Create SFTP connection in NetBox.
2. Put several DOCX-files on server in question.
3. Open connection as FAR panel
4. Open first DOCX file (press "Enter" on file)
5. Close file (close Word's window)
6. Open second DOCX file (press "Enter" in file) FAR crashed

Expected behavior

Second file is downloaded & opened

Actual behavior

FAR crashes.

bug_report.txt

I cannot upload far.mdmp here, but can provide it.

[ssvine]

Far has a bug here. It doesn't update plugin's panel in this case.

[blacklion]

Far has a bug here. It doesn't update plugin's panel in this case.

Nothing changes on server. File is not changed locally, only viewed... Nothing to update.

[ssvine]

Nothing changes on server. File is not changed locally, only viewed... Nothing to update.

You are using Word that can somehow update document properties, whatsoever. To check this, you can enable logging in NetBox, then search your log for Transfer done: string.

[Px-x64]

Not reproducible for me on current build under Windows 10/Word 2016, I was able to open 3 test documents in a row. FreeBSD is 14.2, but I don't think it is important here. Antivirus issue?

[blacklion]

@Px-x64 I'm not surprised, as it started without touching FAR or server, after one of updates to Windows and/or Office. It was rather old FAR3 version (I don't remember which, but something about 1-2 years old), which started to crash in this scenario without any touches to FAR itself. I've updated FAR to latest stable version (indicated in bug report), but it didn't help.

Antivirus is standard MS Defender with default settings, nothing 3rd party is installed.

I can provide any additional information, dumps, etc. or try some experiments / debug versions / whatever.

I'll try to check for transfers (as @ssvine suggest) tomorrow and report back.

[Px-x64]

I've tested on up-to-date OS/Office, despite it is Office 2016. My point is that maybe there is some additional component/item/something, which started to manifest in your case with that update. Maybe it is somehow related to the files you are opening, try with the simplest files with a single line inside.

[blacklion]

I think difference exactly between MSO2016 and (some latest revision of) MSO2021

But, anyway, FAR and plugins should not crash even if external software behaves badly.

I'll try with simpler files (though these are simple enough, single-page pure-text ones) too and report back.

[ssvine]

I reproduced the problem with Word 2003. When opening a temporary local file, Word creates an Object ID (FSCTL_CREATE_OR_GET_OBJECT_ID) which results in the ChangeTime being updated. This causes Far to upload the file to the remote, exactly what I said earlier.

So, it's a bug in Far that doesn't force the plugin to update a panel - the same problem can be reproduced for arclite plugin, although without a crash:

1. Create an archive files.7z with two files a.txt and b.txt containing aaa and bbb strings respectively.
2. Open files.7z using arclite plugin.
3. Press Enter on b.txt to open the file in notepad.exe.
4. Remove anything from the file, save it, and close the notepad.
5. A dialog named Add files to archive appears. Update the archive.
6. Go to b.txt and press F3 (internal viewer). You'll see aaa instead of an empty file. Go to a.txt and press F3 (internal viewer). You'll see an empty file instead of aaa.
7. Press Ctrl-R to refresh the panel. Check that all files are ok.

[blacklion]

I think, any metadata update on temporary files should be ignored (if file is really unchanged) in case of all such plugins. Repack archive or re-upload file only for changed mtime or access rights on temporary file (!) is useless. Only content changes should trigger re-pack or re-upload, in systematic way.

[Px-x64]

6. Go to b.txt and press F3 (internal viewer). You'll see aaa instead of an empty file. Go to a.txt and press F3 (internal viewer). You'll see an empty file instead of aaa.

I can confirm this. Note, that in header the correct file name is shown :)