| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1008.1 | | SMURF::SCOTT | | Fri Feb 28 1997 14:35 | 14 |
| pat,
On which release do you see this problem?
A quick test on my V4.0 system shows statvfs to return the correct
f_basetype field. In my case, I nfs mounted an advfs filesystem, and
statvfs returned a basetype of nfsv3 (correct).
Was your customer perhaps running statvfs on the filesystem server rather
that on the client? To detect from the server that a filesystem is being
nfs exported requires reading the local kernel's export database. See the
exportfs(2) manpage for details.
larry
|
| 1008.2 | <statvfs> | CSC32::P_HILL | | Tue Mar 04 1997 16:50 | 61 |
| I was trying to work this issue for pat so I tried
to get more info from customer. this is on unix 4.0a release
I sent a copy of the stub pat created to customer to make sure
the fields in the buffer are the same as the customer, so we are
not comparing apples to oranges and he replied back with:
Got your file and compared it to mine. No difference at all, except
that
I don't think you can guage whether a file is nfs mounted by the sign
of
it's inode device. I read you could do this, but in my testing, it
doesn't work this way. I've included some runs of my program below:
## on a local file, /vmunix
stat(/vmunix) returns
st_dev (device of inode): -1028731763
st_ino (inode number): 947
st_mode (mode bits): 33261
st_nlink (number of links to file): 1
st_uid (uid): 0
st_gid (gid): 0
st_rdev (for special files): 0
st_size (file size in characters): 9132736
st_atime (time last accessed): Tue Feb 25 13:22:08 1997
st_mtime (time last modified): Sat Dec 21 12:45:40 1996
st_ctime (time node last changed): Sat Dec 21 12:45:51 1996
st_blksize (size of block in file): 8192
st_blocks (blocks allocated for file): 17840
st_flags (user defined flags for file): 0
st_gen (file generation number): 32772
## on a mounted file, /home/support/rlwall/.cshrc
stat(/home/support/rlwall/.cshrc) returns
st_dev (device of inode): 135266305
st_ino (inode number): 39853
st_mode (mode bits): 33204
st_nlink (number of links to file): 1
st_uid (uid): 1005
st_gid (gid): 1000
st_rdev (for special files): 0
st_size (file size in characters): 869
st_atime (time last accessed): Tue Mar 4 16:42:03 1997
st_mtime (time last modified): Sat Jan 4 08:39:46 1997
st_ctime (time node last changed): Wed Jan 15 13:50:21 1997
st_blksize (size of block in file): 8192
st_blocks (blocks allocated for file): 2
st_flags (user defined flags for file): 0
st_gen (file generation number): 0
according to the customer he states stat() seems to do the
opposite of what the pat's program assumes: when the inode
device is negative the file seems to be local, but when the device
is positive, it seems nfs mounted
Thanks Paul osappl
|
| 1008.3 | statvfs != stat | SMURF::SCOTT | | Tue Mar 04 1997 17:54 | 13 |
| Paul,
The data you present appears to be generated from a stat() call; stat()
returns information about a target file. The previous entries in this
topic discussed using statvfs(), which returns filesystem information.
Also, you cannot determine filesystem type based on the inode device #.
Can you explain your question? Are you asking a question separate from
that posed in .0? Or is someone using the wrong program to obtain the
filesystem type?
larry
|
| 1008.4 | Sorry. Paul sent the customer an early test program. Not the one I posted in .0 | PEACHS::LAMPERT | Pat Lampert, UNIX Applications Support, 343-1050 | Wed Mar 05 1997 13:18 | 15 |
| Hi.
The customer is all set. Turns out he was not using the
buffer->f_basetype from statvfs. I had assumed he was, and
didnt really run my own test. Sorry.
The example posted by Paul was an early iteration of code I used.
The code tested an assumption made be the Perl stat function.
The assumption that nfs device numbers will be negative only
works on Ultrix. Fails on Digital UNIX. The Perl documentation
says it will "usually" be negative. So I have no problem with
this.
Pat
|