Re: NCPFS flags all files executable on NetWare Volumes wit
Petr Vandrovec wrote:
>
>
>
> In kernel fs/ncpfs/ncplib_kernel.c, there is function named
> ncp_del_file_or_subdir() which does:
>
> #ifdef CONFIG_NCPFS_NFS_NS
> if (server->name_space[volnum] == NW_NS_NFS)
> {
> int result;
>
> result = ncp_obtain_DOS_dir_base(server, volnum, dirent, name, );
> if (result) return result;
> return ncp_DeleteNSEntry(server, 1, volnum, dirent, NULL, NW_NS_DOS,
>htons(0x0680));
What wrong here is you have to read in each NS record (and the records
for the parent
file) and modify them. You are just doing one and expecting the server
to do the work
of unlinking just the one. You have to do each link yourself. I will
fix.
> }
> else
> #endif
> return ncp_DeleteNSEntry(server, 1, volnum, dirent, name,
>server->name_space[volnum], htons(0x0680));
>
> If you'll remove #ifdef-ed part, and you'll try to unlink some file
> using NFS namespace, server dies (on traditional filesystem, NSS works)
> with some internal inconsistency found error. Depending on search
> attributes (0x8006) passed to function, it either works only for directories
> (and abend for files), or works only for dirs (and refuses files), or
> does not work at all.
>
>
> > You can expose these as .files the way HFS likes to see them, and MAC
> > clients to a Linux box
> > will be able to see and store their data in native MAC format -- with
> > finder info.
>
> It is possible when using DOS or OS/2 namespace. But as NFS namespace
> allows all byte sequences up to 255 chars for filename (excluding chars
> 0, '/' and names "." and "..")...
I have code that translates MAC to DOS, DOS to NFS, NFS to MAC, etc.
You have to convert the
names using the tables in NWFS, file NWCREATE.C. There are tables I use
to generate the
MAC names from an NFS name using these tables of valid and invalid
characters for each
namespace. I have to do it for all the server Namespaces, since Netware
can cross mount
NWFS volumes created under Linux.
Jeff
> Best regards,
> Petr Vandrovec
> [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/
Re: NCPFS flags all files executable on NetWare Volumes wit
On 27 Oct 00 at 15:14, Jeff V. Merkey wrote:
> Petr Vandrovec wrote:
> >
> > On 27 Oct 00 at 13:46, Jeff V. Merkey wrote:
> > > 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.
> >
> > Thanks. Main problem with hardlinks is that unlink through NFS namespace
> > kills server (at least up to 5.0, I did not checked it during last few
> > months), and unlink through DOS (or OS2) namespace removes all instances
> > of hardlinked file :-( A bit unfortunate behavior.
>
> Where are you doing this in the code? I'll go look at it and attempt a
> fix. It's killing the server because the linkage fields are probably
> not getting set. If NFSSERV is loaded, and the
In kernel fs/ncpfs/ncplib_kernel.c, there is function named
ncp_del_file_or_subdir() which does:
#ifdef CONFIG_NCPFS_NFS_NS
if (server->name_space[volnum] == NW_NS_NFS)
{
int result;
result = ncp_obtain_DOS_dir_base(server, volnum, dirent, name, );
if (result) return result;
return ncp_DeleteNSEntry(server, 1, volnum, dirent, NULL, NW_NS_DOS,
htons(0x0680));
}
else
#endif
return ncp_DeleteNSEntry(server, 1, volnum, dirent, name,
server->name_space[volnum], htons(0x0680));
If you'll remove #ifdef-ed part, and you'll try to unlink some file
using NFS namespace, server dies (on traditional filesystem, NSS works)
with some internal inconsistency found error. Depending on search
attributes (0x8006) passed to function, it either works only for directories
(and abend for files), or works only for dirs (and refuses files), or
does not work at all.
> links ever get hosed, you will get an Abend on 3.x and 4.x, and a
> "process suspended" error on 5.x (which also hangs the server). If the
It is always without any modifications through NFS namespace info, as
I'm not using it at all.
> also because these linkage fields are not getting set properly. It does
> not work this way
> with the NetWare NFSSERV.NLM mounted as an NFS client from Linux.
NUC interface is also OK (as unixware happily uses that), only NCP 87,8
is broken. I did not ever tried to unlink file if NFSSERV is loaded...
> > > /6804 Return Bindery Context (you need to implement this one
> > > -- I did not see it in your code)
> >
> > ncpfs 2.2.0.18 implements this (lib/ds/bindctx.c:NWDSGetBinderyContext),
> > but does not use it itself...
>
> It should. It will allow you to use NDS with your existing code and NCP
> suite. I guess
> doug's next project at TRG will be to put in NDS support in NCPFS and
> submit the patches to you.
ncpfs (2.2.0.18/2.2.0.19pre) supports almost complete documented NWDS*
set of functions. Only thing missing are ACL assigning code, you must
do it yourself through NWDSModifyObject calls.
> > Userspace ncpfs (specifically ncopy) uses
> > (lib/filemgmt.c:ncp_ns_open_create_entry) NCP 87,30 or 87,33 for this
> > (and NW3.x is out of luck, AFAIK). Kernel code does not support MAC
> > forks (and ACL and extended attributes), as up to now there is no
> > vfs API for this... You have to use ncopy,nwdir/nwrights,
> > nwtrustee,...,nwdir/eaops,nwdir for accessing MAC()/ACL/EAs for now.
> > (for EAs you must have post-August 27 ncpfs, betas are on
> > ftp://platan.vc.cvut.cz/private/ncpfs)
>
> You can expose these as .files the way HFS likes to see them, and MAC
> clients to a Linux box
> will be able to see and store their data in native MAC format -- with
> finder info.
It is possible when using DOS or OS/2 namespace. But as NFS namespace
allows all byte sequences up to 255 chars for filename (excluding chars
0, '/' and names "." and "..")...
Best regards,
Petr Vandrovec
[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/
Re: NCPFS flags all files executable on NetWare Volumes wit
Petr Vandrovec wrote: > > On 27 Oct 00 at 13:46, Jeff V. Merkey wrote: > > 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. > > Thanks. Main problem with hardlinks is that unlink through NFS namespace > kills server (at least up to 5.0, I did not checked it during last few > months), and unlink through DOS (or OS2) namespace removes all instances > of hardlinked file :-( A bit unfortunate behavior. Where are you doing this in the code? I'll go look at it and attempt a fix. It's killing the server because the linkage fields are probably not getting set. If NFSSERV is loaded, and the links ever get hosed, you will get an Abend on 3.x and 4.x, and a "process suspended" error on 5.x (which also hangs the server). If the wrong pipe of fifo octals get set in mode, it will also hang the server. If it is removing the entire namespace with hardlinks, it's also because these linkage fields are not getting set properly. It does not work this way with the NetWare NFSSERV.NLM mounted as an NFS client from Linux. > > > 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. > > Not for now. > > > /6804 Return Bindery Context (you need to implement this one > > -- I did not see it in your code) > > ncpfs 2.2.0.18 implements this (lib/ds/bindctx.c:NWDSGetBinderyContext), > but does not use it itself... It should. It will allow you to use NDS with your existing code and NCP suite. I guess doug's next project at TRG will be to put in NDS support in NCPFS and submit the patches to you. > > > /6805 Monitor NDS Connection (this one will allow you to > > intercept NDS replica packets and suck an NDS replica local) > > Novell documentation is a bit - hmm - unclear on this one... There's some undocumented diagnostic calls in NDS that basically render it totally unsuitable for the internet and make it easy to hack. It's great for LANs in an organization where the servers can all be locked up, and employees can get fired for hacking. On the internet, it's a piece of "swiss cheese" and is vulnerable in many respects. > > > /1631 Open Data Stream (this NCP will allow you to open the > > MAC namespace data fork and read it remotely for MAC clients) > > Userspace ncpfs (specifically ncopy) uses > (lib/filemgmt.c:ncp_ns_open_create_entry) NCP 87,30 or 87,33 for this > (and NW3.x is out of luck, AFAIK). Kernel code does not support MAC > forks (and ACL and extended attributes), as up to now there is no > vfs API for this... You have to use ncopy,nwdir/nwrights, > nwtrustee,...,nwdir/eaops,nwdir for accessing MAC()/ACL/EAs for now. > (for EAs you must have post-August 27 ncpfs, betas are on > ftp://platan.vc.cvut.cz/private/ncpfs) You can expose these as .files the way HFS likes to see them, and MAC clients to a Linux box will be able to see and store their data in native MAC format -- with finder info. Jeff > Thanks, > Petr Vandrovec > [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/ - 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/
Re: NCPFS flags all files executable on NetWare Volumes wit
On 27 Oct 00 at 13:46, Jeff V. Merkey wrote: > 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. Thanks. Main problem with hardlinks is that unlink through NFS namespace kills server (at least up to 5.0, I did not checked it during last few months), and unlink through DOS (or OS2) namespace removes all instances of hardlinked file :-( A bit unfortunate behavior. > 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. Not for now. > /6804 Return Bindery Context (you need to implement this one > -- I did not see it in your code) ncpfs 2.2.0.18 implements this (lib/ds/bindctx.c:NWDSGetBinderyContext), but does not use it itself... > /6805 Monitor NDS Connection (this one will allow you to > intercept NDS replica packets and suck an NDS replica local) Novell documentation is a bit - hmm - unclear on this one... > /1631 Open Data Stream (this NCP will allow you to open the > MAC namespace data fork and read it remotely for MAC clients) Userspace ncpfs (specifically ncopy) uses (lib/filemgmt.c:ncp_ns_open_create_entry) NCP 87,30 or 87,33 for this (and NW3.x is out of luck, AFAIK). Kernel code does not support MAC forks (and ACL and extended attributes), as up to now there is no vfs API for this... You have to use ncopy,nwdir/nwrights, nwtrustee,...,nwdir/eaops,nwdir for accessing MAC()/ACL/EAs for now. (for EAs you must have post-August 27 ncpfs, betas are on ftp://platan.vc.cvut.cz/private/ncpfs) Thanks, Petr Vandrovec [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/
Re: NCPFS flags all files executable on NetWare Volumes wit
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 /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) indexbytes type or valuedescription 0 6structure Request Packet Header 6 20x5716 NCP Function Code 8 1Namespace Namespace number (0-DOS, 2-NFS, 4-LONG, 1-MAC) 9 3reserved '000''s 121Volume Number The volume the file resides in. 134 ComponentHandle 171 ComponentHandleFlag 181 The number of components in ComponentPath 191...? ComponentPath Reply Packet (17 bytes) indexbytes type or valuedescription 0 8structure Server Response Header 8 4 The directory base of the file or directory in the namespace associated with Namespace 124 The directory base of the file or directory in the DOS Name Space (The FAT Chain head) 161 Volume Number Completion codes 0x00 OK 2. NCP code /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 bytestype or value description 0 6structure Request Packet Header 6 20x5717 NCP Function Code 8 1 Namespace 9 1 Volume Number Reply Packet (154 bytes) index bytestype or value description 0 8structure 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 /5719 Set Name Space Information Attempts to set iformation specific to the name space for the specified entity. Request Packet (531 bytes) index bytestype or value description 0 6structureRequestPacketHeader 6 20x5719 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 bytestype or valuedescription 0 8structureServerResponseHeader Completion Codes 0x00 OK 4. NCP code222/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 0x571BNCPFunctionCode 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
Re: NCPFS flags all files executable on NetWare Volumes wit
On Fri, Oct 27, 2000 at 10:57:54AM -0600, Jeff V. Merkey wrote:
> On Fri, Oct 27, 2000 at 03:00:31PM +, 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_LINK2
#define NFS_HARD_LINK3
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]
Re: NCPFS flags all files executable on NetWare Volumes wit
On Fri, Oct 27, 2000 at 03:00:31PM +, 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]".
-
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/
Re: NCPFS flags all files executable on NetWare Volumes wit
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]".
-
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/
Re: NCPFS flags all files executable on NetWare Volumes wit
On Fri, Oct 27, 2000 at 03:00:31PM +, 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]".
-
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/
Re: NCPFS flags all files executable on NetWare Volumes wit
On Fri, Oct 27, 2000 at 10:57:54AM -0600, Jeff V. Merkey wrote:
On Fri, Oct 27, 2000 at 03:00:31PM +, 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_LINK2
#define NFS_HARD_LINK3
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
Re: NCPFS flags all files executable on NetWare Volumes wit
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 /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) indexbytes type or valuedescription 0 6structure Request Packet Header 6 20x5716 NCP Function Code 8 1Namespace Namespace number (0-DOS, 2-NFS, 4-LONG, 1-MAC) 9 3reserved '000''s 121Volume Number The volume the file resides in. 134 ComponentHandle 171 ComponentHandleFlag 181 The number of components in ComponentPath 191...? ComponentPath Reply Packet (17 bytes) indexbytes type or valuedescription 0 8structure Server Response Header 8 4 The directory base of the file or directory in the namespace associated with Namespace 124 The directory base of the file or directory in the DOS Name Space (The FAT Chain head) 161 Volume Number Completion codes 0x00 OK 2. NCP code /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 bytestype or value description 0 6structure Request Packet Header 6 20x5717 NCP Function Code 8 1 Namespace 9 1 Volume Number Reply Packet (154 bytes) index bytestype or value description 0 8structure 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 /5719 Set Name Space Information Attempts to set iformation specific to the name space for the specified entity. Request Packet (531 bytes) index bytestype or value description 0 6structureRequestPacketHeader 6 20x5719 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 bytestype or valuedescription 0 8structureServerResponseHeader Completion Codes 0x00 OK 4. NCP code222/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 0x571BNCPFunctionCode 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
Re: NCPFS flags all files executable on NetWare Volumes wit
On 27 Oct 00 at 13:46, Jeff V. Merkey wrote: 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. Thanks. Main problem with hardlinks is that unlink through NFS namespace kills server (at least up to 5.0, I did not checked it during last few months), and unlink through DOS (or OS2) namespace removes all instances of hardlinked file :-( A bit unfortunate behavior. 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. Not for now. /6804 Return Bindery Context (you need to implement this one -- I did not see it in your code) ncpfs 2.2.0.18 implements this (lib/ds/bindctx.c:NWDSGetBinderyContext), but does not use it itself... /6805 Monitor NDS Connection (this one will allow you to intercept NDS replica packets and suck an NDS replica local) Novell documentation is a bit - hmm - unclear on this one... /1631 Open Data Stream (this NCP will allow you to open the MAC namespace data fork and read it remotely for MAC clients) Userspace ncpfs (specifically ncopy) uses (lib/filemgmt.c:ncp_ns_open_create_entry) NCP 87,30 or 87,33 for this (and NW3.x is out of luck, AFAIK). Kernel code does not support MAC forks (and ACL and extended attributes), as up to now there is no vfs API for this... You have to use ncopy,nwdir/nwrights, nwtrustee,...,nwdir/eaops,nwdir for accessing MAC(FTAM)/ACL/EAs for now. (for EAs you must have post-August 27 ncpfs, betas are on ftp://platan.vc.cvut.cz/private/ncpfs) Thanks, Petr Vandrovec [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/
Re: NCPFS flags all files executable on NetWare Volumes wit
Petr Vandrovec wrote: On 27 Oct 00 at 13:46, Jeff V. Merkey wrote: 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. Thanks. Main problem with hardlinks is that unlink through NFS namespace kills server (at least up to 5.0, I did not checked it during last few months), and unlink through DOS (or OS2) namespace removes all instances of hardlinked file :-( A bit unfortunate behavior. Where are you doing this in the code? I'll go look at it and attempt a fix. It's killing the server because the linkage fields are probably not getting set. If NFSSERV is loaded, and the links ever get hosed, you will get an Abend on 3.x and 4.x, and a "process suspended" error on 5.x (which also hangs the server). If the wrong pipe of fifo octals get set in mode, it will also hang the server. If it is removing the entire namespace with hardlinks, it's also because these linkage fields are not getting set properly. It does not work this way with the NetWare NFSSERV.NLM mounted as an NFS client from Linux. 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. Not for now. /6804 Return Bindery Context (you need to implement this one -- I did not see it in your code) ncpfs 2.2.0.18 implements this (lib/ds/bindctx.c:NWDSGetBinderyContext), but does not use it itself... It should. It will allow you to use NDS with your existing code and NCP suite. I guess doug's next project at TRG will be to put in NDS support in NCPFS and submit the patches to you. /6805 Monitor NDS Connection (this one will allow you to intercept NDS replica packets and suck an NDS replica local) Novell documentation is a bit - hmm - unclear on this one... There's some undocumented diagnostic calls in NDS that basically render it totally unsuitable for the internet and make it easy to hack. It's great for LANs in an organization where the servers can all be locked up, and employees can get fired for hacking. On the internet, it's a piece of "swiss cheese" and is vulnerable in many respects. /1631 Open Data Stream (this NCP will allow you to open the MAC namespace data fork and read it remotely for MAC clients) Userspace ncpfs (specifically ncopy) uses (lib/filemgmt.c:ncp_ns_open_create_entry) NCP 87,30 or 87,33 for this (and NW3.x is out of luck, AFAIK). Kernel code does not support MAC forks (and ACL and extended attributes), as up to now there is no vfs API for this... You have to use ncopy,nwdir/nwrights, nwtrustee,...,nwdir/eaops,nwdir for accessing MAC(FTAM)/ACL/EAs for now. (for EAs you must have post-August 27 ncpfs, betas are on ftp://platan.vc.cvut.cz/private/ncpfs) You can expose these as .files the way HFS likes to see them, and MAC clients to a Linux box will be able to see and store their data in native MAC format -- with finder info. Jeff Thanks, Petr Vandrovec [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/ - 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/
Re: NCPFS flags all files executable on NetWare Volumes wit
On 27 Oct 00 at 15:14, Jeff V. Merkey wrote:
Petr Vandrovec wrote:
On 27 Oct 00 at 13:46, Jeff V. Merkey wrote:
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.
Thanks. Main problem with hardlinks is that unlink through NFS namespace
kills server (at least up to 5.0, I did not checked it during last few
months), and unlink through DOS (or OS2) namespace removes all instances
of hardlinked file :-( A bit unfortunate behavior.
Where are you doing this in the code? I'll go look at it and attempt a
fix. It's killing the server because the linkage fields are probably
not getting set. If NFSSERV is loaded, and the
In kernel fs/ncpfs/ncplib_kernel.c, there is function named
ncp_del_file_or_subdir() which does:
#ifdef CONFIG_NCPFS_NFS_NS
if (server-name_space[volnum] == NW_NS_NFS)
{
int result;
result = ncp_obtain_DOS_dir_base(server, volnum, dirent, name, dirent);
if (result) return result;
return ncp_DeleteNSEntry(server, 1, volnum, dirent, NULL, NW_NS_DOS,
htons(0x0680));
}
else
#endif
return ncp_DeleteNSEntry(server, 1, volnum, dirent, name,
server-name_space[volnum], htons(0x0680));
If you'll remove #ifdef-ed part, and you'll try to unlink some file
using NFS namespace, server dies (on traditional filesystem, NSS works)
with some internal inconsistency found error. Depending on search
attributes (0x8006) passed to function, it either works only for directories
(and abend for files), or works only for dirs (and refuses files), or
does not work at all.
links ever get hosed, you will get an Abend on 3.x and 4.x, and a
"process suspended" error on 5.x (which also hangs the server). If the
It is always without any modifications through NFS namespace info, as
I'm not using it at all.
also because these linkage fields are not getting set properly. It does
not work this way
with the NetWare NFSSERV.NLM mounted as an NFS client from Linux.
NUC interface is also OK (as unixware happily uses that), only NCP 87,8
is broken. I did not ever tried to unlink file if NFSSERV is loaded...
/6804 Return Bindery Context (you need to implement this one
-- I did not see it in your code)
ncpfs 2.2.0.18 implements this (lib/ds/bindctx.c:NWDSGetBinderyContext),
but does not use it itself...
It should. It will allow you to use NDS with your existing code and NCP
suite. I guess
doug's next project at TRG will be to put in NDS support in NCPFS and
submit the patches to you.
ncpfs (2.2.0.18/2.2.0.19pre) supports almost complete documented NWDS*
set of functions. Only thing missing are ACL assigning code, you must
do it yourself through NWDSModifyObject calls.
Userspace ncpfs (specifically ncopy) uses
(lib/filemgmt.c:ncp_ns_open_create_entry) NCP 87,30 or 87,33 for this
(and NW3.x is out of luck, AFAIK). Kernel code does not support MAC
forks (and ACL and extended attributes), as up to now there is no
vfs API for this... You have to use ncopy,nwdir/nwrights,
nwtrustee,...,nwdir/eaops,nwdir for accessing MAC(FTAM)/ACL/EAs for now.
(for EAs you must have post-August 27 ncpfs, betas are on
ftp://platan.vc.cvut.cz/private/ncpfs)
You can expose these as .files the way HFS likes to see them, and MAC
clients to a Linux box
will be able to see and store their data in native MAC format -- with
finder info.
It is possible when using DOS or OS/2 namespace. But as NFS namespace
allows all byte sequences up to 255 chars for filename (excluding chars
0, '/' and names "." and "..")...
Best regards,
Petr Vandrovec
[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/
Re: NCPFS flags all files executable on NetWare Volumes wit
Petr Vandrovec wrote:
In kernel fs/ncpfs/ncplib_kernel.c, there is function named
ncp_del_file_or_subdir() which does:
#ifdef CONFIG_NCPFS_NFS_NS
if (server-name_space[volnum] == NW_NS_NFS)
{
int result;
result = ncp_obtain_DOS_dir_base(server, volnum, dirent, name, dirent);
if (result) return result;
return ncp_DeleteNSEntry(server, 1, volnum, dirent, NULL, NW_NS_DOS,
htons(0x0680));
What wrong here is you have to read in each NS record (and the records
for the parent
file) and modify them. You are just doing one and expecting the server
to do the work
of unlinking just the one. You have to do each link yourself. I will
fix.
}
else
#endif
return ncp_DeleteNSEntry(server, 1, volnum, dirent, name,
server-name_space[volnum], htons(0x0680));
If you'll remove #ifdef-ed part, and you'll try to unlink some file
using NFS namespace, server dies (on traditional filesystem, NSS works)
with some internal inconsistency found error. Depending on search
attributes (0x8006) passed to function, it either works only for directories
(and abend for files), or works only for dirs (and refuses files), or
does not work at all.
You can expose these as .files the way HFS likes to see them, and MAC
clients to a Linux box
will be able to see and store their data in native MAC format -- with
finder info.
It is possible when using DOS or OS/2 namespace. But as NFS namespace
allows all byte sequences up to 255 chars for filename (excluding chars
0, '/' and names "." and "..")...
I have code that translates MAC to DOS, DOS to NFS, NFS to MAC, etc.
You have to convert the
names using the tables in NWFS, file NWCREATE.C. There are tables I use
to generate the
MAC names from an NFS name using these tables of valid and invalid
characters for each
namespace. I have to do it for all the server Namespaces, since Netware
can cross mount
NWFS volumes created under Linux.
Jeff
Best regards,
Petr Vandrovec
[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/
