On 27 Oct 00 at 0:16, Jeff V. Merkey wrote:
> I noticed NCPFS is flagging all the files on a native NetWare volume as
> executable and chmod -x does not work, even if the NetWare server has
> the NFS namespace loaded. I looked at you code in more detail, and I
> did not see support their for the NFS/Unix namespace.
> Is this in a newer version, or has it not been implemented yet? I was
> testing with MARS and Native NetWare this evening and saw this. If the
> NFS namespace is loaded, you should be able to get to it and access and
> set all these bits in the file system namespace directory records.
>
> Do you need any info from me to get this working, or is there another
> version where I can get this for Ute-Linux?
Hi Jeff,
ncpfs does not support NFS fields, as access through namespace functions
is hopelessly broken (modify ns specific info has swapped some bits
in mask which data update and which not), and it also adds some (100%)
overhead on directory/inode lookups, as you must ask twice - first for
non-NFS info, and second for NFS specific...
There exists patch from Ben Harris <[email protected]>, which adds
this feature to 2.2.16 kernel and 2.2.0.17 ncpfs. You can download
it from ftp://platan.vc.cvut.cz/pub/linux/ncpfs/ncp{1,2}.pat. ncp1.pat
is kernel patch (including email headers; cut them if applying), ncp2.pat
is patch for 2.2.0.17 ncpfs userspace - it adds mount option "nfsextras".
(I apologize to Ben - I promised to integrate it into ncpfs, and into
2.4 kernel, but...)
Except that, you can make all files non-executable by using
"filemode=0644" mount option. Or you can use "extras,symlinks", in which
case (NFS namespace incompatible) hidden/shareable/transactional attributes
are used to signal executability of file...
If you have some document which describes what each NFS specific field
does - currently ncpfs names them "name", "mode", "gid", "nlinks", "rdev",
"link", "created", "uid", "acsflag" and "myflag" - if I remember correctly,
it is how Unixware 2.0 nuc.h names them. And I did not found any information
about layout of NFS huge info, which is used for hardlinks :-(
Also, as NCP 87,8 kills almost every NW server I know, if used namespace
is NFS, I'm a bit sceptic about usability of NCP 87,* on NFS namespace.
In 1998 and 1999 I tried to ask Novell for documentation of NCP 95,*
(Netware Unix Client), but it was refused and ignored, so... here we are.
Best regards,
Petr Vandrovec
[email protected]
P.S.: Jeff, if you want, there is ncpfs/MaRS/LinWare specific list,
[email protected]. Subscribe: "subscribe linware" to "[email protected]".
On Fri, Oct 27, 2000 at 03:00:31PM +0000, Petr Vandrovec wrote:
> On 27 Oct 00 at 0:16, Jeff V. Merkey wrote:
> > I noticed NCPFS is flagging all the files on a native NetWare volume as
> > executable and chmod -x does not work, even if the NetWare server has
> > the NFS namespace loaded. I looked at you code in more detail, and I
> > did not see support their for the NFS/Unix namespace.
>
> > Is this in a newer version, or has it not been implemented yet? I was
> > testing with MARS and Native NetWare this evening and saw this. If the
> > NFS namespace is loaded, you should be able to get to it and access and
> > set all these bits in the file system namespace directory records.
> >
> > Do you need any info from me to get this working, or is there another
> > version where I can get this for Ute-Linux?
>
> Hi Jeff,
> ncpfs does not support NFS fields, as access through namespace functions
> is hopelessly broken (modify ns specific info has swapped some bits
> in mask which data update and which not), and it also adds some (100%)
> overhead on directory/inode lookups, as you must ask twice - first for
> non-NFS info, and second for NFS specific...
>
> There exists patch from Ben Harris <[email protected]>, which adds
> this feature to 2.2.16 kernel and 2.2.0.17 ncpfs. You can download
> it from ftp://platan.vc.cvut.cz/pub/linux/ncpfs/ncp{1,2}.pat. ncp1.pat
> is kernel patch (including email headers; cut them if applying), ncp2.pat
> is patch for 2.2.0.17 ncpfs userspace - it adds mount option "nfsextras".
> (I apologize to Ben - I promised to integrate it into ncpfs, and into
> 2.4 kernel, but...)
>
> Except that, you can make all files non-executable by using
> "filemode=0644" mount option. Or you can use "extras,symlinks", in which
> case (NFS namespace incompatible) hidden/shareable/transactional attributes
> are used to signal executability of file...
>
> If you have some document which describes what each NFS specific field
> does - currently ncpfs names them "name", "mode", "gid", "nlinks", "rdev",
> "link", "created", "uid", "acsflag" and "myflag" - if I remember correctly,
> it is how Unixware 2.0 nuc.h names them. And I did not found any information
> about layout of NFS huge info, which is used for hardlinks :-(
>
> Also, as NCP 87,8 kills almost every NW server I know, if used namespace
> is NFS, I'm a bit sceptic about usability of NCP 87,* on NFS namespace.
>
> In 1998 and 1999 I tried to ask Novell for documentation of NCP 95,*
> (Netware Unix Client), but it was refused and ignored, so... here we are.
> Best regards,
> Petr Vandrovec
> [email protected]
Petr,
I've got the info you need including the layout of the NFS namspace
records. For a start, grab NWFS and look at the NFS structure in
NWDIR.H. The fields you have to provide are there. There are some
funky ones in this structure. You are correct regarding the NCP
extensions to support this. They are about 12 years old, BTW and are
not even supported any longer (no one has worked on this at Novell
since about 1994).
I will put together a complete description today (will take a couple
of hours) and post to the list on the implementation of of the NFS
namespace over the wire. Hardlinks use a root DirNo handle that
must point back to the DOS namespace record that owns the FAT chain
and this is probably the only nasty thing to deal with here.
I'll get started immediately.
:-)
Jeff
>
> P.S.: Jeff, if you want, there is ncpfs/MaRS/LinWare specific list,
> [email protected]. Subscribe: "subscribe linware" to "[email protected]".
On Fri, Oct 27, 2000 at 10:57:54AM -0600, Jeff V. Merkey wrote:
> On Fri, Oct 27, 2000 at 03:00:31PM +0000, Petr Vandrovec wrote:
> > On 27 Oct 00 at 0:16, Jeff V. Merkey wrote:
> > > I noticed NCPFS is flagging all the files on a native NetWare volume as
> > > executable and chmod -x does not work, even if the NetWare server has
> > > the NFS namespace loaded. I looked at you code in more detail, and I
> > > did not see support their for the NFS/Unix namespace.
> >
> > > Is this in a newer version, or has it not been implemented yet? I was
> > > testing with MARS and Native NetWare this evening and saw this. If the
> > > NFS namespace is loaded, you should be able to get to it and access and
> > > set all these bits in the file system namespace directory records.
> > >
> > > Do you need any info from me to get this working, or is there another
> > > version where I can get this for Ute-Linux?
> >
> > Hi Jeff,
> > ncpfs does not support NFS fields, as access through namespace functions
> > is hopelessly broken (modify ns specific info has swapped some bits
> > in mask which data update and which not), and it also adds some (100%)
> > overhead on directory/inode lookups, as you must ask twice - first for
> > non-NFS info, and second for NFS specific...
> >
> > There exists patch from Ben Harris <[email protected]>, which adds
> > this feature to 2.2.16 kernel and 2.2.0.17 ncpfs. You can download
> > it from ftp://platan.vc.cvut.cz/pub/linux/ncpfs/ncp{1,2}.pat. ncp1.pat
> > is kernel patch (including email headers; cut them if applying), ncp2.pat
> > is patch for 2.2.0.17 ncpfs userspace - it adds mount option "nfsextras".
> > (I apologize to Ben - I promised to integrate it into ncpfs, and into
> > 2.4 kernel, but...)
> >
> > Except that, you can make all files non-executable by using
> > "filemode=0644" mount option. Or you can use "extras,symlinks", in which
> > case (NFS namespace incompatible) hidden/shareable/transactional attributes
> > are used to signal executability of file...
> >
> > If you have some document which describes what each NFS specific field
> > does - currently ncpfs names them "name", "mode", "gid", "nlinks", "rdev",
> > "link", "created", "uid", "acsflag" and "myflag" - if I remember correctly,
Oh, and:
created is always set to 1 for the root entry.
acsflag is whehter NetWare or the NFS client last accessed the file
name is the name
mode CANNOT contain NFS v3.0 style permissions it's on v2.0 -- pipe and
fifo will hang the NetWare server, so mask these off.
nlinks is the number of hardlinks to a file.
rdev is the same as rdev in Linux
flags(myflag) contains the following values:
#define NFS_HASSTREAM_HARD_LINK 1 // indicates this record has the FAT chain
#define NFS_SYMBOLIC_LINK 2
#define NFS_HARD_LINK 3
There's also three linkage fields you have to fill out:
LinkNextDirNo // next record in the hardlink chain
LinkEndDirNo // always the dir record that holds the fat chain
LinkPreDirNo // previous record in the hardlink chain
records are added at the HEAD and not the TAIL of the linkage. The
root record is always at the END and not the HEAD of the list.
:-)
Jeff
I'll go dig up the specific NCP extensions and get them to you.
:-)
Jeff
> > it is how Unixware 2.0 nuc.h names them. And I did not found any information
> > about layout of NFS huge info, which is used for hardlinks :-(
> >
> > Also, as NCP 87,8 kills almost every NW server I know, if used namespace
> > is NFS, I'm a bit sceptic about usability of NCP 87,* on NFS namespace.
> >
> > In 1998 and 1999 I tried to ask Novell for documentation of NCP 95,*
> > (Netware Unix Client), but it was refused and ignored, so... here we are.
> > Best regards,
> > Petr Vandrovec
> > [email protected]
>
>
> Petr,
>
> I've got the info you need including the layout of the NFS namspace
> records. For a start, grab NWFS and look at the NFS structure in
> NWDIR.H. The fields you have to provide are there. There are some
> funky ones in this structure. You are correct regarding the NCP
> extensions to support this. They are about 12 years old, BTW and are
> not even supported any longer (no one has worked on this at Novell
> since about 1994).
>
> I will put together a complete description today (will take a couple
> of hours) and post to the list on the implementation of of the NFS
> namespace over the wire. Hardlinks use a root DirNo handle that
> must point back to the DOS namespace record that owns the FAT chain
> and this is probably the only nasty thing to deal with here.
>
> I'll get started immediately.
>
> :-)
>
> Jeff
>
>
>
>
> >
> > P.S.: Jeff, if you want, there is ncpfs/MaRS/LinWare specific list,
> > [email protected]. Subscribe: "subscribe linware" to "[email protected]".
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
Petr,
Here's the complete set of 3.x/4.x/5.x Namespace NCP calls with proper
return codes. I'll run down the huge-data info and post a bit later.
1.
NCP code 2222/5716
Generate Directory Base and Volume Number
Returns the directory base for the file or directory in the name space
associated with
"namespace"
Request Packet (20 to ? bytes)
index bytes type or value description
0 6 structure Request Packet Header
6 2 0x5716 NCP Function Code
8 1 Namespace Namespace number (0-DOS, 2-NFS,
4-LONG, 1-MAC)
9 3 reserved '000''s
12 1 Volume Number The volume the file resides in.
13 4 ComponentHandle
17 1 ComponentHandleFlag
18 1 The number of components in
ComponentPath
19 1...? ComponentPath
Reply Packet (17 bytes)
index bytes type or value description
0 8 structure Server Response Header
8 4 The directory base of the file or
directory in the
namespace associated with
Namespace
12 4 The directory base of the file or
directory in the DOS Name Space (The FAT Chain head)
16 1 Volume Number
Completion codes
0x00 OK
2.
NCP code 2222/5717
Query Name Space Information Format
Attempts to return the format of the information for the specified name
space on the volume associated with VolumeNumber.
Request Packet (10 bytes)
index bytes type or value description
0 6 structure Request Packet Header
6 2 0x5717 NCP Function Code
8 1 Namespace
9 1 Volume Number
Reply Packet (154 bytes)
index bytes type or value description
0 8 structure ServerResponseHeader
8 4 fixed bit mask
12 4 variable bit mask
16 4 huge bit mask
20 2 fixed bits defined
22 2 variable bits defined
24 2 huge bits defined
26 128 fields length table (for NFS,
this is the NFS structure in NWDIR.H in NWFS)
Completion codes
0x00 OK
3.
NCP code 2222/5719
Set Name Space Information
Attempts to set iformation specific to the name space for the specified
entity.
Request Packet (531 bytes)
index bytes type or value description
0 6 structure RequestPacketHeader
6 2 0x5719 NCPFunctionCode
8 1 Source Name Space
9 1 Destination Name Space
10 1 Volume Number
11 4 DirEntry
15 4 NSInfoBitMask
19 512 NSSpecificInfo (the modified
namespace records)
Reply Packet (8 bytes)
index bytes type or value description
0 8 structure ServerResponseHeader
Completion Codes
0x00 OK
4.
NCP code 222/571B
Set Huge Name Space Information
Attempts to set the huge Namespace information for the entity associated
with DirEntry
Request Packet (39 bytes)
index bytes type of value description
0 6 structure RequestPacketHeader
6 2 0x571B NCPFunctionCode
8 1 Namespace
9 1 Volume Number
10 4 DirEntry
14 4 HugeMask
18 16 HugeStateInfo
34 4 HugeDataLength
38 1 HugeData
Reply Packet (28 bytes)
index bytes type or value description
0 8 structure ServerResponseHeader
8 16 HugeStateInfo
24 4 Total Amount of Huge Data Used
Completion Code
0x00 OK
I have the formats for the other NameSpace NCPs, but it looks like your
code is handling these. If you need them,
let me know. I have a 600 page document I wrote two years ago that
details every single NCP and NDS NCP used,
and can send it to you via UPS in .cz. It's too big to fax, or post.
The format of the namespace records is the same as in NWDIR.H in NWFS --
NetWare just passes them through to the client
so all the field layouts are there. Unless the NFS server is loaded on
NetWare, you can just about write anythin you
want into the NFS namespace, since NetWare does not check the namespace
records (other than the first seven common fields
that are the same for all namespace records). If NFSSERV.NLM loads on
the server, he does do a consistency check and
will vrepair the volume if any of the fields are hosed.
Other NCPs you may need (let me know if you need these as well) -- looks
like you are already implementing these correctly.
2222/5714 Get Name Space Information
2222/5715 Search for a File or Subdirectory
2222/5715 Get Path String from Short Dir Handle
2222/5718 Get Name Spaces Loaded List from Volume Number
2222/571C Get Full Path String
2222/571D Get Effective Directory Rights
2222/6801 Ping for NDS NCP
2222/6802 Send NDS FRagment/Reply
2222/6803 Close NDS Fragment
2222/6804 Return Bindery Context (you need to implement this one
-- I did not see it in your code)
2222/6805 Monitor NDS Connection (this one will allow you to
intercept NDS replica packets and suck an NDS replica local)
2222/162F Get Name Space Information
2222/1630 Get Name Space Directory Entry
2222/1631 Open Data Stream (this NCP will allow you to open the
MAC namespace data fork and read it remotely for MAC clients)
:-)
Jeff