I am using NFAU SP4 on a Netware 5.1 server SP7, exporting for a RedHat 9
box to backup
some files via its rsync. Out of about 5,000 files which are fine, there
are about 6
that behave very strangely: their filenames appear to be exported
incorrectly. The
same problem appears with simple commands like ls (dir) as well as rsync. I
have been
checking this out for over a month and I don't think it is something simple.
I
concentrated on the first filename that failed, a700.tst.
Using a packet sniffer (Ethereal), for a correct case (e.g. a simple "ls
?699.???"
which will give one result, "a699.tst") the sequence of RPC packets is:

ACCESS request (from RedHat)
ACCESS reply (from Netware)
GETATTR request (for a directory)
GETATTR reply
GETATTR request (again for a directory)
GETATTR reply
ACCESS request (for a directory)
ACCESS reply
ACCESS request (again for a directory)
ACCESS reply
GETATTR request (for a file)
GETATTR reply

For a failed case (e.g. a simple "ls ?700.???" which _should_ give one
result,
"a700.tst" but gives "ls: A700.TST No such file or directory") the sequence
of RPC
packets is:

ACCESS request (from RedHat)
ACCESS reply (from Netware)
GETATTR request (for a directory)
GETATTR reply
GETATTR request (again for a directory)
GETATTR reply
ACCESS request (for a directory)
ACCESS reply
ACCESS request (again for a directory)
ACCESS reply
LOOKUP request (for a file)
LOOKUP Reply (Gives Error:ERR_NOENT)

Apart from this last call, there are no RPC errors (the Ethereal dump for
this packet
is at the end of this message). _Maybe_ Netware is sending A700.TST instead
of
a700.tst, but because the objects are hashed in the RPC packets, I cannot be
sure.
This error persists across Netware SP5, 6 & 7 and NFAU SP3 & 4. I also
tried renaming
& naming it back, deleting it, etc., and also a full rebuild of the NSS
volume (in case
the namespace was corrupt, because that rebuilt the namespaces), but the
error _always_
happens with a700.tst!

Is this a Netware bug? Is there any way I can "unhash" the objects to see
exactly what
they are? If I force RedHat to use RPC V2 instead of RPC V3, will the
objects be in
"unhashed" format?

Thanks in advance for any clues,

Ciaran Costelloe

-----------------------------------------
Frame 381 (158 bytes on wire, 158 bytes captured)
Arrival Time: Feb 19, 2004 13:29:04.037115000
Time delta from previous packet: 0.028400000 seconds
Time since reference or first frame: 2.245415000 seconds
Frame Number: 381
Packet Length: 158 bytes
Capture Length: 158 bytes
Ethernet II, Src: 00:b0:d0:d0:01:17, Dst: 00:02:b3:bd:0a:22
Destination: 00:02:b3:bd:0a:22 (Intel_bd:0a:22)
Source: 00:b0:d0:d0:01:17 (DellComp_d0:01:17)
Type: IP (0x0800)
Internet Protocol, Src Addr: 192.168.1.120 (192.168.1.120), Dst Addr:
192.168.1.1

(192.168.1.1)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 144
Identification: 0x3da0 (15776)
Flags: 0x00
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: UDP (0x11)
Header checksum: 0x78f3 (correct)
Source: 192.168.1.120 (192.168.1.120)
Destination: 192.168.1.1 (192.168.1.1)
User Datagram Protocol, Src Port: nfs (2049), Dst Port: 800 (800)
Source port: nfs (2049)
Destination port: 800 (800)
Length: 124
Checksum: 0x0f74 (correct)
Remote Procedure Call, Type:Reply XID:0x571da324
XID: 0x571da324 (1461560100)
Message Type: Reply (1)
Program: NFS (100003)
Program Version: 3
Procedure: LOOKUP (3)
Reply State: accepted (0)
This is a reply to a request in frame 361
Time from request: 0.028400000 seconds
Verifier
Flavor: AUTH_NULL (0)
Length: 0
Accept State: RPC executed successfully (0)
Network File System, LOOKUP Reply Error:ERR_NOENT
Program Version: 3
V3 Procedure: LOOKUP (3)
Status: ERR_NOENT (2)
dir_attributes
attributes_follow: value follows (1)
attributes
Type: Directory (2)
mode: 0755
0... .... .... = not SUID
.0.. .... .... = not SGID
..0. .... .... = not save swapped text
...1 .... .... = Read permission for owner
.... 1... .... = Write permission for owner
.... .1.. .... = Execute permission for owner
.... ..1. .... = Read permission for group
.... ...0 .... = no Write permission for group
.... .... 1... = Execute permission for group
.... .... .1.. = Read permission for others
.... .... ..0. = no Write permission for others
.... .... ...1 = Execute permission for others
nlink: 1
uid: 4294967294
gid: 4294967294
size: 4096
used: 0
rdev: 0,0
specdata1: 0
specdata2: 0
fsid: 7111
fileid: 368771
atime: Feb 7, 2003 15:19:21.000000000
seconds: 1044631161
nano seconds: 0
mtime: Jan 7, 2004 17:15:09.000000000
seconds: 1073495709
nano seconds: 0
ctime: Feb 7, 2003 15:19:21.000000000
seconds: 1044631161
nano seconds: 0

0000 00 02 b3 bd 0a 22 00 b0 d0 d0 01 17 08 00 45 00 ....."........E.
0010 00 90 3d a0 00 00 80 11 78 f3 c0 a8 01 78 c0 a8 ..=.....x....x..
0020 01 01 08 01 03 20 00 7c 0f 74 57 1d a3 24 00 00 ..... .|.tW..$..
0030 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0040 00 00 00 00 00 02 00 00 00 01 00 00 00 02 00 00 ................
0050 01 ed 00 00 00 01 ff ff ff fe ff ff ff fe 00 00 ................
0060 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 ................
0070 00 00 00 00 00 00 00 00 00 00 00 00 1b c7 00 00 ................
0080 00 00 00 05 a0 83 3e 43 ce 79 00 00 00 00 3f fc ......>C.y....?.
0090 3e 9d 00 00 00 00 3e 43 ce 79 00 00 00 00 >.....>C.y....