Messages in this thread |  | | Date | Sun, 19 Nov 2000 22:53:05 -0700 | From | "Jeff V. Merkey" <> | Subject | Re: NCPFS not returning Volume Size (???) |
| |
On Sun, Nov 19, 2000 at 05:10:06PM +0100, Petr Vandrovec wrote: > On Thu, Nov 16, 2000 at 08:40:29PM -0700, Jeff V. Merkey wrote: > > Petr, > > > > NCPFS in 2.2.18-pre21 is not returning volume size via df -h. I checked > > your code and found this comment: > > > > static int ncp_statfs(struct super_block *sb, struct statfs *buf, int bufsiz) > > { > > NCP Code > > > > 2222/17E6 Get Object's Remaining Disk Space > > > > I noticed that 2.4 also is not reporting Volume free space. > > Yes, it is intentional. There are two different things: > (1) you can mount all volumes from server to one mountpoint, and all these > volumes share one superblock. So it is not clear, which value to > return. Sum of all volume sizes? > (2) in Netware, each directory can have its own space limit, so > returned free space should differ from directory to directory. > As statfs is per-superblock thing, I believe that returning > 'sorry, I do not know' is better. > > > grouped into case/switch classes. If you can point me to > > where 1) the login ID is stored and B) where NCP packet > > request/reponse headers are constructed, i.e. a skeleton > > to send/receive the requests I can grab, I'll try to > > code this for you. > > loginID is not stored anywhere in kernel. You can look at > ioctl(,NCP_IOC_GETOBJECTNAME,...). If you need your own ID > so you know which disk space restriction retrieve, you'll have > to first execute retrieve logged in info for current connection > (where connection number is stored in server->connection). > > request/reply is built in preallocated space, you can look > at functions in ncplib_kernel.c, f.e. ncp_open_create_file_or_subdir > uses almost every of ncp_add_* functions. ncp_request() then > executes RPC call and ncp_unlock_server() unlocks connection. > You must NOT access userspace between ncp_init_request() > and ncp_unlock_server() function, or deadlock can occur. >
There's is a method to obtain this accurately. NSS may have changed some things. I have a list of four issues now with this one I need to get finished. I may need some help with your code as I go.
Jeff
> Best regards, > Petr Vandrovec > vandrove@vc.cvut.cz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |