NCPFS flags all files executable on NetWare Volumes wit

Quoted 5 lines · Petr Vandrovec

Quoted 2 lines · Jeff V. Merkey

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.

Quoted 4 lines

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

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.

Quoted 5 lines

Quoted 2 lines

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.

Quoted 8 lines

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.

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.

Quoted 4 lines

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]