Xref: utzoo comp.bugs.sys5:455 comp.unix.wizards:9023 Path: utzoo!attcan!uunet!munnari!moncskermit!labtam!timr From: timr@labtam.OZ (Tim Roper) Newsgroups: comp.bugs.sys5,comp.unix.wizards Subject: Re: File System Type (statfs, sysfs) Summary: use st_dev from stat(2) Keywords: System V Release 3.1.1 Version 3 for AT&T 3B2 Message-ID: <681@labtam.OZ> Date: 31 May 88 13:51:00 GMT References: <479@uniq.UUCP> Organization: Labtam Limited., Melbourne, Australia Lines: 27 In article <479@uniq.UUCP>, rjnoe@uniq.UUCP (Roger J. Noe) writes: > The following pertains to UNIX System V Release 3.1.1 Version 3 for the AT&T > 3B2 computer. Perhaps I have misunderstood the purpose of the statfs(2) > system call, but when I use it on remote file systems (RFS), I always get > the same file system type as local (non-RFS) file systems. The following > program illustrates my point: > ... When you statfs(2) a remote (RFS) file, f_fstyp gives the filesystem index from the remote machine. Beware that eg. if "S51K" on the remote machine is a different index to what it is on the local machine you get the *former*. This can and does happen if the local and remote machines have different filesystems configured. Therefore using sysfs(GETFSTYP, ...) to map an f_fstyp obtained from statfs(2) onto a name is not correct in general, as sysfs(2) uses the local mapping. If you stat(2) a remote file you get the high order bit of st_dev turned on so you can tell that it is remote if you want to. Also the major number tells which machine it resides on. And the minor number tells which filesystem on the remote machine the file resides on. The major and minor are uninteresting on their own but can be used to see whether two files reside on the same machine and/or filesystem. I understand that this is so that programs like cp(1) that decide whether two files are the same by comparing st_dev and st_ino still work (unless you "remotely" mount a local filesystem). -Tim. D