Hi,

I'm currently evaluating the callback file system as being suitable to replace our NSE implementation.

One problem I have is that enumerate is called with the path that the user is currently looking at. In order for me to be able to enumerate a directory, I need two private pieces of information that the user will never see. As far as I can tell there is no way to store this information?

For instance at the top level, I'm passed an empty string - I will then return a list of entities where each entity has a uniqueid (invisible to the user) and a filename (which the user sees and may not be unique). When the user navigates down to the next sub-level, I then need that unique id in order to return the next list of entities - each of which has an integer id that together with the top level id make up an identifier for the file - which are then used to enumerate further.

Is there anyway to store user info within the TCbFsFileInfo element - or anywhere else that can then be returned to me on all calls?

Regards
Keith

Thank you for a good question. I have asked the developer to look at it and think what can be done.

OK, thanks - I'd appreciate it if you can keep me posted as I need to make a decision by mid week next week as to whether we do this or not (personally I think this is the best way to go as it would be a lot more flexible than the NSE).

Regards
Keith

It looks like you have to use the unique file names in any case. I understand what you are trying to achieve however there are cases which you can't avoid. Example: you have created disk Z:. Now the user just types dir z:\dir1\*.* knowing (from previous experience) that dir1 exists (at least he saw this name before). You don't have an ID1=dir1 mapping yet as you have not read it from the database (or remote location or whatever). You must find dir1. To do this, you must ensure that dir1 is some unique name. All I can see is that you use "ID_filename.ext" form when creating/reporting the file names to the users. I.e. append the (possibly non-unique) file name to the unique ID and then dealing with such names.

OK. Things have moved on slightly as it proved to be impossible to efficiently use a drive letter as the the drives are remote on a relatively slow connection and the amount of traffic would make it far too slow - for example some of the files are music files and the os will therefore attempt to open the file, read the meta information and close the file again every time the folder is opened, and for image files, it will constantly be trying to extract thumbnails.

Therefore the intention is to attempt to use som,e sort of a hybrid with the NSE giving all the visual information (which it extracts from a db) and using the driver with a \\.\ mountpoint to allow files to be manipulated with standard windows applications.

Regards
Keith.

Quote

Keith Giddings wrote: OK. Things have moved on slightly as it proved to be impossible to efficiently use a drive letter as the the drives are remote on a relatively slow connection and the amount of traffic would make it far too slow - for example some of the files are music files and the os will therefore attempt to open the file, read the meta information and close the file again every time the folder is opened, and for image files, it will constantly be trying to extract thumbnails.

It's possible to specify the drive mapped by callback file system as a remote drive, but this doesn't completely solve this kind of problems - most likely thumbnails will be extracted anyway.