vfs interface - ioctl question

[Anu Engineer]

Hi , 

 I completely agree, the right thing to do is to create an NTFS
emulation layer that do NTFS like functions that is done currently in
SAMBA. But When do you plan to do such an Interface, is it planned for 
near future ?

As regards the IOCTL usage, what would happen is that each File System
maintainer would have to have his own separate patch , that is SAMBA
will support only Unix File Systems as it does right now. Each Physical
File System person who wants to use IOCTLs would have to maintain there
own patches, But that is irrelevant if you are able to create a
ntfs->posix layer.

regards
Anu

Ps. I have been thinking about this problem of how samba is constructed
as a Windows-to-Unix Gateway, it would have been nice if samba had a 3
level architecture, One that deals with the Network ( SMB stuff ) gives
you a clean packet interface at the end ,  another than deal with lots
of CIFS-isms like Open in read mode with Truncate, support for search
attributes in a path operation like delete( Utils layer - like current
samba with  unix_convert, check_name ... )  and a third layer that did
the ntfs->Posix emulation ( I think the current VFS layer is a bit too
Unix specific) 


This will allow SAMBA to run on all kinds of file systems, the classic
one will be a file system that is quite like NTFS in Unix but will be
able to run SAMBA over it. Currently if I have a NTFS like file system
with ACL's ( Windows Acl's ) and other meta-data information then one
needs to go into SAMBA and change code. Where as if you can cleanly
re-define these interfaces then it will be much more easier to support
more complex( diverse)  file systems.











On Mon, 2002-11-25 at 17:22, Simo Sorce wrote:
> On Mon, 2002-11-25 at 23:52, Anu Engineer wrote:
> > Hi ,
> > 
> > I have been looking at the SAMBA VFS layer, and I have a request 
> > for a function to be added to the interface.
> > 
> > I would like to propose an ioctl like function where file system defined
> > parameters can be passed back and forth between SAMBA and physical
> > file-system. 
> > 
> > This will be useful in cases where the file system supports some
> > features over and above ordinary Unix file systems. For example,
> > Creation Time, if we have an ioctl call we can use that to set and get
> > creation time on files with minimum modification to samba.
> 
> The right thing is to support all the features an NTFS support.
> We are already planning to radically change the interface to be more
> flexible and, above all to make the ntfs->posix translation a module so
> that it can be replaced for richer or different then posix file systems.
> 
> > I propose something of the form
> > 
> > int 
> > vfs_ioctl( struct connection_struct * conn, struct files_struct * fsp,
> > ...);
> > 
> > or something like 
> > 
> > int 
> > vfs_ioctl ( struct connection_struct * conn, struct files_struct * fsp,
> > ulong cmd, void * inbuf,size_t in_size,  void* outbuf, size_t out_size).
> 
> > of course I realize the nightmare of maintaining an IOCTL list, but I am
> > hoping in the case of SAMBA it would not be as bad as something like an
> > OS, and  this feature will be used to add extensions to SAMBA so that
> > the capabilities of underlying file systems can be reflected more
> > accurately in SAMBA.
> 
> I'm not sure this is a good idea.
> How would you like to use these ioctl then?
> 
> Simo.
-- 
Anu Engineer <anu at engineer.com>