Bug 65920 - [nwfs] Mounted Netware filesystem behaves strange
Summary: [nwfs] Mounted Netware filesystem behaves strange
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-fs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-04-23 20:30 UTC by Feczak Szabolcs
Modified: 2014-08-11 18:51 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Feczak Szabolcs 2004-04-23 20:30:17 UTC
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
Comment 1 Feczak Szabolcs 2004-08-27 11:51:24 UTC
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.
Comment 2 Mark Linimon freebsd_committer freebsd_triage 2004-11-21 01:57:36 UTC
Responsible Changed
From-To: freebsd-i386->freebsd-bugs

Canonicalize assignment.
Comment 3 Antony Mawer 2006-04-19 00:39:13 UTC
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?
Comment 4 Gavin Atkinson freebsd_committer freebsd_triage 2009-04-16 12:47:06 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-fs

Over to maintainer(s)
Comment 5 John Baldwin freebsd_committer freebsd_triage 2014-08-11 18:51:32 UTC
NWFS is no longer supported in the base system.