SFTP unable to handle "control.ini"

I use a file called “control.ini” on a web server. I’ve changed the server to a synology NAS, and updated the script. FinalBuilder is now unable to do anything with a file called “control.ini” on the server. It reports “Connection to the SFTP server has been lost.” if I try to upload it. Renaming the destination file in the action has it work fine. Any combination of “controlnew.ini” or “controlini” works. So I figured I’d upload it and rename it. But SFTP delete doesn’t remove a file with that name. Any other name seems fine. And rename of the file to the “control.ini” fails too.

Now, it used to work on another server. But I can do anything on the file from another client. And I can’t see anything relevant on the web regarding the file name and SFTP or Synology.

Is there anything “significant” in FinalBuilder with that name? Any clues really very welcome!

No, FinalBuilder doesn’t know anything about specific filenames. I will test this on Monday as we have a Synology nas in the office.

If the file was there before, my guess is permissions with the existing file?

There was no previous file, and I could create one, rename one, delete one from other client. And FB was working fine with other files - ironically the control.ini is the last, so I thought it must be local. But it can upload the same file with another name. Totally bizarre!

What version of FinalBuilder are you using?

I was originally on an older version, then reported as per version 8.0.0.2508 and have no installed build 2516. Incidentally, the check for updates returns an error saying it didn’t understand <p>

Below is the log - it seems to me that there is something “tripping up” the SFTP component.

Oh wow, done some experimentation and it is failing with any 7.3 file name. A simple 1234567.123 fails too, but add an 8 and it works. Take the 6, it works.
No idea where to go from that, but any 7 letter name and 3 letter extension seems to fail guaranteed. I hope this helps!

Matthew


Action Messages:
Connecting to ‘myserver.com’ on port 4422.
Connecting…
Setting Authtypes to keyboard and password
Received Server Key [77c092c20e05fbd66373d2b418c28e40].
Starting Authentication…
Attempting Authentication type: [4]
Authenticated OK.
Server public key cached: 77c092c20e05fbd66373d2b418c28e40
Connected to myserver.com
Server Software : OpenSSH_7.4
Server SFTP Protocol Version : 3
SFTP Upload File - Myfile.exe

Action Messages:
Acquiring connection object
Uploading c:\src\MyFolder\Distribution\Server\Myfile.exe
Uploaded [c:\src\MyFolder\Distribution\Server\Myfile.exe] to [MyFolder/updates/Myfile-50.exe]
Releasing connection object
SFTP Upload File - control.ini

Action Messages:
Acquiring connection object
Uploading C:\src\MyFolder\Controller\control.ini
Upload of ‘C:\src\MyFolder\Controller\control.ini’ to ‘MyFolder/updates/control.ini’ failed: SFTP component not connected
Releasing connection object

---- Retry with upload under other name, delete name and then rename to proper. Connect skipped for brevity.

Action Messages:
Acquiring connection object
Uploading C:\src\MyFolder\Controller\control.ini
Uploaded [C:\src\MyFolder\Controller\control.ini] to [MyFolder/updates/controlnew.ini]
Releasing connection object
SFTP Remove File - [LocalTest]

Action Messages:
Acquiring connection object
Removing MyFolder/updates/control.ini
File removed.
Releasing connection object
SFTP Rename File - [LocalTest]

Action Messages:
Acquiring connection object
Connection to the SFTP server has been lost.
Releasing connection object

Hmmm… must be something in secureblackbox, as I checked our code and we don’t do anything with filenames other than pass them into the library code. I’ll look into this.

I just tested this here with the latest FinalBuilder on our synology nas running DSM 6.2.1-23824 Update 4 (installing update 6 now) and it worked fine with any filenames of any length.

what version of DSM are you running?

I didn’t change any settings on the nas other than to turn on sftp.

Tested with update 6 with the same result. Not sure where to go from here.

Well, I can’t explain it either - nothing in the Synology logs, was pretty up to date with only one more update to apply. Certainly not “out of date”.

Just in case it adds to a future resolution, I’m running in a VMWare Fusion VM, and I tried with the Windows Firewall turned off. Nothing I can see to get in the way of such. And particularly SFTP I’d expect to be hard to intercept at a firewall level anyway. The Synology logs the good transfers, but nothing on the failed ones.

Ah well, not critical to me right now, so I will leave it. Thanks for looking. If someone else has this, I hope we can work out the common factor and solve it. For now, let’s not dig further.