how to avoid "Not enough data" exception on file delete over sftp?

Question

Getting an exception on sftp.Delete(remoteFileName, TraversalMode.MatchFilesShallow);
"System.InvalidOperationException: Not enough data"

I tried to look it up and found the the questions:
8032/not-enough-data
and
9851/system-invalidoperationexception-not-enough-data
on this forum.
I tried to solve my issue based on those info but I did not succeeed - see below

Our binaries are old, but still a year after 2016. Anyway, I tried with the 30day trial of the current version.
Same results.

I tried other commands as well:
DirectoryExists, FileExists and Delete all throws the saem exception.

I saw there should be some workaround, also spotted the DisableFxpStatWorkaround setting. I checked it is false by default, so it should do the workaround but it does not do it.
In fact I tried the following things:

based on 8032/not-enough-data
sftpClient.Settings.DisableFxpStatWorkaround = false; sftpClient.Settings.DisableRealPathWorkaround = false; sftpClient.Settings.EnableBrokenDirectoryStatWorkaround = true; sftpClient.Settings.EnableBrokenRealPathWorkaround = true;

based on 9851/system-invalidoperationexception-not-enough-data
Rebex.Security.Cryptography.CryptoHelper.SetOption(sftpClient, "EnableRedundantCreateTimeWorkaround", true);

The latter just throw an exception about a non valid option.

I saw that the most probable cause of the server - on which I have no influence. But I also saw in such cases some workaround is possible.
Can you help me to sort this out?

This is the verbose log for the Delete command with the built in rebex file log writer

2022-02-10 12:40:07.986 INFO Sftp(1)[38] Batch: Calling Delete(string = 'BEGlobalNetDESADV20220208-090510-849.txt', TraversalMode = 'MatchFilesShallow').
2022-02-10 12:40:08.007 DEBUG Sftp(1)[38] Batch: Executing multi-file operation: Deleting, source = '.', target = '', TransferMethod.Copy, MoveMode.All, LinkProcessingMode.FollowLinks, ActionOnExistingFiles.ThrowException.
2022-02-10 12:40:08.009 DEBUG Sftp(1)[38] Batch: Normalizing source path ('.').
2022-02-10 12:40:08.009 DEBUG Sftp(1)[38] Batch: Checking source path ('/OUT').
2022-02-10 12:40:08.012 VERBOSE Sftp(1)[38] SSH: Sending packet SSHMSGCHANNELDATA (30 bytes).
0000 |5E-00-00-00-00-00-00-00 15-00-00-00-11-07-00-00| ^...............
0010 |00-2B-00-00-00-04-2F-4F 55-54-00-00-00-BD | .+..../OUT....
2022-02-10 12:40:08.012 INFO Sftp(1)[38] Command: SSHFXPLSTAT (43, '/OUT')
2022-02-10 12:40:08.036 VERBOSE Sftp(1)[44] SSH: Received packet SSHMSGCHANNELDATA (73 bytes).
0000 |5E-00-00-00-00-00-00-00 40-00-00-00-3C-69-00-00| ^.......@...<i..
0010 |00-2B-00-00-00-BD-02-00 00-00-00-00-00-20-00-00| .+........... ..
0020 |00-00-08-6D-75-6C-74-69 5F-64-6B-00-00-00-06-73| ...multidk....s
0030 |61-70-73-79-73-00-00-0D FF-00-00-00-00-62-04-E4| apsys........b..
0040 |90-00-00-00-00-62-04-E4 90 | .....b...
2022-02-10 12:40:08.057 ERROR Sftp(1)[38] Info: System.InvalidOperationException: Not enough data.
at gjgit.sjyuo.bpypj()
at gjgit.sjyuo.qxllw()
at Rebex.Net.SftpAttributes..ctor(sjyuo parser, Int32 version)
at gjgit.dzaqq..ctor(Byte[] buffer, Int32 offset, Int32 count, Encoding encoding, Int32 version)
at gjgit.qpfmw.oiker(rfiqv& p0)
at gjgit.qpfmw.cbiyt(UInt32 p0, Boolean p1)
at gjgit.qpfmw.zvozf(rfiqv p0, UInt32 p1, wtgcv p2)
at gjgit.qpfmw.keiqw(String p0, Boolean p1, Boolean p2, Boolean p3, Boolean p4, uztdn p5, xozeo& p6, wtgcv p7)
at Rebex.Net.Sftp.nexhd(String p0, Boolean p1, Boolean p2, Boolean p3, Boolean p4, wtgcv p5)

Answer 1

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 mod_sftp 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 mod_sftp in its SSH server identification string.

Update: Starting with Rebex SFTP R6.3, the workaround can be enabled using Sftp.Settings.EnableMissingCreateTimeWorkaround.

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 SSH_FXP_ATTRS 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!

Comments

Thank you,
I appreciate the detailed answer.
For anybody who finds this:
The CryptoHelper workaround works - in this post there is no typo ;)

---

Thanks a lot! We'll most likely publish this option as public bool Sftp.Settings.EnableMissingCreateTimeWorkaround property in the next release.

---

Sftp.Settings.EnableMissingCreateTimeWorkaround is now available: https://www.rebex.net/sftp.net/history.aspx#R6.3

---

Great! Thank you!