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...
> > > 2222/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]
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]
>