Incorrect duplicate file detection with custom FileSystemProvider

Question

We're using a custom file system provider (inherited from ReadWriteFileSystemProvider) and currently have a failing test asserting the correct behavior of a duplicate file being uploaded. We're expecting to see an error message indicating the file already exists; but instead it shows 'I/O error.'.

To rule out the issue being in our custom implementation we also tested with the default LocalFileSystemProvider and MemoryFileSystemProvider implementations, which show the same behavior.

The issue is reproducable with this sample: https://github.com/richardkooiman/Rebex.FileServer/tree/main/DuplicateFileBug.

Output when running the sample application:

Starting application...
Configuring Rebex file server...
Configured Rebex file server...
Starting Rebex file server...
Started Rebex file server.
Performing file uploads for success user...
Performing file uploads for fail user...
ERROR - Expected to catch exception indicating file already exists, but instead got exception with message: 'I/O error.'.
Finished running application.

Comments

Thanks for the report.  I apologize for the inconvenience this might have caused.
I have reproduced this problem with Renci SSH client.
The problem is caused by the adapter that translates VFS exceptions to specific File System exceptions.
We will look into this and most likely fix the problem in the next release of Rebex Components. If you prefer a preview build with the change, let me know.

I cannot reproduce the problem with the Rebex SFTP client.
  
Thanks again for your report.

---

Thanks a lot for looking into this.

I had thought about the possibility of the issue being with the SFTP client (in our case, Renci SSH.NET) (mis)interpreting a valid response from the Rebex SFTP server. However, that does not explain the difference in behavior between a user without a FileSystemProvider (which gives the duplicate file message) and a user with a Rebex built-in FileSystemProvider (which does not give the duplicate file message).
Doesn't that mean some of the providers are not throwing the correct/expected exceptions?

Would a preview build also be available through NuGet? In that case we'd be interested. :)

Thanks again!

---

Thanks for the question.
The user WITHOUT FileSystemProvider does not use virtual file system infrastructure at all.
The user WITH any FileSystemProvider uses virtual file system infrastructure. Only virtual file systems are exposed to the Rebex SFTP server using the adapter.
Although virtual file systems (VFS) are tightly integrated with the SFTP server, it's good to know that they are, in fact, standalone and independent components.
In the case you have described you experience some friction between both components/worlds.
The adapter between VFS and the SFTP server has two main responsibilities.
1) The adapter is an "anti-corruption layer" that prevents leaking SFTP details to VFS infrastructure.
2) The adapter does its best when it emulates direct access to the physical file system ('user without FileSystemProvider') using the VFS interface. We are still improving the adapter capabilities.
As you can imagine, the adapter tries hard to hide the unrepresentable details about specific VFS storage, and, in converse, maps disparate traits of the different VFS storage to a common SFTP denominator.

Apparently, as you discovered, the adapter is still not perfect. In one place sends a generic I/O error instead of the more specific 'file does not exist' error.
Rebex client works because its "communication pattern" slightly differs from the "Renci SSH" communication with the server, and Renci SSH activates different branches of the code in the adapter.

Simply put, the problem does not lie in (some) VFS providers that do not throw expected exceptions.

The difference in behavior you have observed can be reduced to the following points:

1) The 'user WITHOUT FileSystemProvider' does not use VFS, so the SFTP client does not have a chance to activate the 'throw general I/O error' in the "VFS<->SFTP adapter".
2) The 'user WITH FileSystemProvider' that uses the Renci SSH client activates the "VFS<->SFTP adapter" logic that throws a general I/O error.

I hope that my simplified explanation makes sense.

I apologize, but we don't publish the prerelease version on the Nuget server.

---

Thanks for the thorough explanation; really appreciate it. I understand now the difference in behavior occurs when using a VFS vs. not using a VFS. Also understood about the pre-release not being available on NuGet. Without rushing you - is there any indication for a timeline for the fix and public release? Thanks again!

---

There will most likely be a new release in a week (or two, if some unforeseen issues pop up).

---

Thanks! Looking foward to it.