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 <[EMAIL PROTECTED]>