Filesystem becomes inaccessable or at least the root mountpoint for a while or till the next "ls" or "file" command issued. Fix: These are not real fixes, just workarounds: 1. repeat ls a number of times in the mountpoint root and it will become available again 2. alternativly issue the tricky : file /mnt/nwfs_mountpoint/directory_which_exist/../. and you do not have to wait at all as in point number one, it will restores normal operation immediately How-To-Repeat: $ mount | grep nwfs /NWSERVER:ADMIN/SDI on /mnt/nwfs (nwfs) So I have the fs mounted, fine $ file /mnt/nwfs/. /mnt/nwfs/.: directory Lets check if the /mnt/nwfs/. reference works .. Since it returns that it is a directory it works $ rm /mnt/nwfs/* rm: /mnt/nwfs/DESKTOP.AFP: is a directory rm: /mnt/nwfs/Icon: Unknown error: 35216 rm: /mnt/nwfs/Network Trash Folder: is a directory rm: /mnt/nwfs/a: is a directory rm: /mnt/nwfs/agica: is a directory rm: /mnt/nwfs/baby: is a directory rm: /mnt/nwfs/data: is a directory rm: /mnt/nwfs/deleted.sav: is a directory rm: /mnt/nwfs/fokonyv: is a directory rm: /mnt/nwfs/test: is a directory rm: /mnt/nwfs/x: is a directory Lets delete the files in the root path of the mount, but not the directories, we got some errors, but it is okay to be so, since no recursion was defined $ cp /tmp/testfile1 /mnt/nwfs Lets copy a normal ascii file to the root dir of the mount $ file /mnt/nwfs/. /mnt/nwfs/.: can't stat `/mnt/nwfs/.' (No such file or directory). and whoala we have problem So it claims that it does not exist, at least the mount is unreachable $ cd /mnt/nwfs $ ls ls: .: No such file or directory And realy it is not Wait a few seconds here, and I got: $ ls DESKTOP.AFP agica fokonyv Icon baby test Network Trash Folder data testfile1 a deleted.sav x $ file /mnt/nwfs/. /mnt/nwfs/.: directory So now it exist and reports that it is a directory .... reachable again But If I do not issue ls or the thing just a little bit lower explained here I got back an error from the file /mnt/nwfs/. command as many times I issue it unless I remount it or make the os rethink this with ls or file command trick. The above process can be repeated unlimited times, and produces the error in every case -> Thats good at least it is consequent and not a random error The above process can be repeated unlimited times, and produces the error in every case -> Thats good at least it is consequent and not a random error Looks like after file operations, the kernel or ncpmount does not refresh the stats on the fs, or has problem with it, since it can not access it for some seconds ... It always makes to behave the mounted fs right instatly If I issue the file /mnt/nwfs/a/../. which is in theory should be equivalent to file /mnt/nwfs/. but in practice it doesn't since, the first one restores the normal behaviour of the filesystem, the second one in the errorous state only returns en error (after first command is issued, the second also works, but If I issue the second one first it claims that it does not exist) You may wonder why Im I refering to /mnt/nwfs as /mnt/nwfs/. because the problem comes from, that I can not rsync it some times and rsync needs to access this directory in the above form. Also strange : $ mkdir /mnt/nwfs/. mkdir: /mnt/nwfs/.: File exists It claims that it exist $ file /mnt/nwfs/. /mnt/nwfs/.: can't stat `/mnt/nwfs/.' (No such file or directory). It claims that it does not exist -> Confusion
The above happend with netware 3.x, I have tested it with a fresh install of 4.11 and FreeBSD 4.10-RELEASE and have NOT experienced the above error.
Responsible Changed From-To: freebsd-i386->freebsd-bugs Canonicalize assignment.
This problem is still present on both FreeBSD 4.11 and FreeBSD 6.0. I've seen it against both Netware 4 servers via IPX, and on Netware 6 running over IP. Performing an rsync backup of one of these servers, it will happily plow along for a while, and then suddenly you get a message like: rsync: read errors mapping "/mnt/data/path/to/some/file.dll": Unknown error: 35208 (35208) WARNING: path/to/some/file.dll failed verification -- update discarded (will try again). Followed by a torrent of "file has vanished" errors. Jumping to the mount-point, I get: $ mount <output trimmed> /10.1.2.3:USER/DATA on /mnt/data (nwfs) $ cd /mnt/data $ ls ls: .: No such file or directory I spoke to Boris Popov a while ago, and he had this to say: "Such behavior usually caused by lost vnode reference and/or bugs in the vnode traversal code. In the case of nwfs this also might be the bugs in the full netware path reconstruction." Does that mean enough to anyone to have a look at anywhere specific in the code, or any suggestions on where I might look?
Responsible Changed From-To: freebsd-bugs->freebsd-fs Over to maintainer(s)
NWFS is no longer supported in the base system.