View Single Post
Old 11-11-2016, 12:56 PM
jimbobmcgee jimbobmcgee is offline
Registered User
Join Date: Apr 2005
Posts: 21
My apologies that I didn't get back to you regarding this -- I never got the forum notification, so missed your reply.

The issue that we are facing is not specific to VShell, but the backgound is that we run a replication tool between the filesystems of two servers running VShell and, if that replication discovers a mismatch, it renames the existing file to originalname.random.conflict and marks it with the 'hidden' and 'read-only' NTFS attributes.

Our clients' process is to enumerate all files in their root, download them for further processing, and then remove them. However, the occasional existence of these *.conflict files is interfering with this process -- either their processing incorrectly attempts to process the conflict file, or they cannot remove it due to the read-only attribute.

The workaround is to request that our clients ignore any *.conflict files that they find, but clients are always reticent to make such changes to their processes and we regularly have to field support calls that remind them of this. It would be better if they never saw these files during their enumeration, so never attempted to process/remove them.

An elegant approach to solving this would be to filter the view of the filesystem, so that *.conflict files were never displayed. I don't know of many options for doing this at the operating system level on Windows, bar ensuring that they are archived very quickly (i.e. out-of-band). However, these files are marked with the NTFS 'hidden' attribute and are always named in the same way.

Ultimately, we are in the process of migrating to a new replication tool, which does its conflict resolution differently, so there is no rush for a solution to this issue but, since we regularly use VShell to provide a client-facing interface, and virtual roots provide a more-configurable abstraction over the underlying filesystem, I thought this might be a nice feature for VShell to have.

The simplest feature request would be for a checkbox on the virtual root configuration which, when checked, forced any SFTP/FTPS directory listing operation within that root to honour the 'hidden' attribute of NTFS, so that files marked as 'hidden' could never form part of the listing.

A more-complex feature request would be for a multiple-entry field table on the virtual root configuration, where each entry could have a 'pattern' field (e.g. '*.tmp') and an 'allow/deny' toggle. The combination of these entries would describe a filter for files that were allowed or disallowed from being returned in a directory listing.

To minimise complications and collisions, the feature would also have to handle the events that a client might attempt to download, upload or delete a file that exists on the underlying filesystem but is filtered by the feature. The end-user should not be able to directly download a file that has been filtered, nor should they be able to create/modify/delete a file that would match the filter.

To maintain client compatibility, I expect this would have to be prevented by returning whatever error response is appropriate -- in FTP(S) this is probably '550' or '553', but in SFTP I think it is more complicated. It might be as simple as just using the generic SSH_FX_FAILURE code for any attempt to do something to a filtered file but, if you were looking for more meaningful messages, you might need to choose a more operation-appropriate message, such as SSH_FX_NO_SUCH_FILE for download and/or delete, SSH_FX_PERMISSION_DENIED or SSH_FX_WRITE_PROTECT for upload or create-directory, and SSH_FX_NO_SUCH_PATH if any of the intermediary directories in the given path were excluded by the filter -- I would have to defer to your protocol experts in this regard.

Last edited by jimbobmcgee; 11-11-2016 at 01:03 PM.
Reply With Quote