If you still get this error with the latest version of Rebex SFTP, the most likely reason is a server-side bug.
A server known to suffer from this issue is ProFTPd 1.3.6's modsftp module, which sends responses with CREATETIME
flag, but missing the corresponding field. Rebex SFTP 2017 R6.1 and later include a workaround for this, but it's only applied if the server includes "modsftp" in its SSH server identification string.
Alternatively, it can be enabled using Rebex.Security.Cryptography.CryptoHelper.SetOption(sftpClient.Settings, "EnableRedundantCreateTimeWorkaround", true)
, but this is only supported in Rebex SFTP R6.1 or later.
Please note that the syntax was wrong in my reply at 9851/system-invalidoperationexception-not-enough-data - the .Settings
part was missing. Sorry for the mistake, I have fixed that now. Please give this a try and let us know whether it resolves the problem.
If you are interested in details, these are the contents of the broken SSHFXPATTRS packet in your verbose log. The 'flags' field indicates presence of three time values, but the response only includes two of them:
00-00-00-3C = SFTP packet length
69 = SSH_FXP_ATTRS packet
00-00-00-2B = SFTP request id
00-00-00-BD = flags SIZE+PERMISSIONS+ACCESSTIME+CREATETIME+MODIFYTIME+OWNERGROUP
02 = directory
00-00-00-00-00-00-20-00 = size
00-00-00-08-6D-75-6C-74-69-5F-64-6B = owner ("multidk")
00-00-00-06-73-61-70-73-79-73 = group ("sapsys")
00-00-0D FF = permissions
00-00-00-00-62-04-E4-90 = a Unix time value
00-00-00-00-62-04-E4 90 = a Unix time value
It's not possible to reliably determine which field is actually missing, so Rebex SFTP raises an error.
The workaround above might help, even though the name of the option seems to be somewhat unrelated (with 'redundant' instead of 'missing'). We'll surely fix that when we add a public setting for this!