Re: Testing if two files are on the same file system

2017-10-26 Thread Joerg Schilling
Stephane Chazelas wrote: > On FreeBSD, gnustat -fc%i returns 0 for everything including UFS > file systems. On Solaris, one seems to get non zero values even > for /proc If this number is used to generate a NFS file handle for NFS export, then the NFS server would

Re: Testing if two files are on the same file system

2017-10-26 Thread Joerg Schilling
Garrett Wollman wrote: > Actually, it is quite well known (just apparently not by the author of > that document). The fsid is used to generate NFS file handles. It's > supposed to be random and unique per file server. (I think also it > was supposed to be hard to guess

Re: Testing if two files are on the same file system

2017-10-25 Thread Stephane Chazelas
2017-10-25 12:01:04 +0200, Martijn Dekker: [...] > > I'm not sure what the output of "LC_ALL=C df -P" should be for a > > mount point like a UTF-8 /home/stéphane > > That's a good point. I had actually added LC_ALL=C to my 'df' > invocation, more out of habit than anything. I should remove it.

Re: Testing if two files are on the same file system

2017-10-25 Thread Stephane Chazelas
2017-10-25 10:11:35 +0200, Vincent Lefevre: > On 2017-10-24 21:11:45 +0200, Joerg Schilling wrote: > > Nick Stoughton wrote: > > > > If you are correct, this is a Linux kernel bug. > > > > > > Why? The stat command is not standardized. The --file-system argument > > >

Re: Testing if two files are on the same file system

2017-10-25 Thread Robert Elz
Date:Wed, 25 Oct 2017 11:17:56 +0200 From:Martijn Dekker Message-ID: | if is onsamefs "$file1" "$file2"; then | ln "$file2" "$file1"# hard links are possible | else | ln -s "$file2"

Re: Testing if two files are on the same file system

2017-10-25 Thread Martijn Dekker
Op 23-10-17 om 17:36 schreef Vincent Lefevre: > The initial question was actually not clear. First, you should define > what a file system is. If this is not what is identified by st_dev[*], > what is it? That's a good point. What I mean is an instance of a file system on a particular device or

Re: Testing if two files are on the same file system

2017-10-25 Thread Robert Elz
Date:Wed, 18 Oct 2017 15:01:23 +0200 From:Martijn Dekker Message-ID: <4d781f3b-085c-d2ca-1912-b08410266...@inlv.org> | Is there a way, using POSIX shell and utilities, to reliably test if two | files are on the same file system? I have been

Re: Testing if two files are on the same file system

2017-10-25 Thread Vincent Lefevre
On 2017-10-24 21:11:45 +0200, Joerg Schilling wrote: > Nick Stoughton wrote: > > > If you are correct, this is a Linux kernel bug. > > > > Why? The stat command is not standardized. The --file-system argument > > changes the output of %i to something other than the inode

Re: Testing if two files are on the same file system

2017-10-25 Thread Garrett Wollman
On October 25, 2017 1:39:01 AM EDT, Stephane Chazelas wrote: >On FreeBSD, gnustat -fc%i returns 0 for everything including UFS >file systems. On Solaris, one seems to get non zero values even >for /proc To find the actual fsid as used in file handles requires

Re: Testing if two files are on the same file system

2017-10-24 Thread Stephane Chazelas
2017-10-25 06:39:01 +0100, Stephane Chazelas: [...] > On FreeBSD, gnustat -fc%i returns 0 for everything including UFS > file systems. [...] Sorry, only if you're not root as hinted in the Linux statfs man page. You do get a non-zero value as root including for devfs and tmpfs on FreeBSD. But

Re: Testing if two files are on the same file system

2017-10-24 Thread Stephane Chazelas
2017-10-24 16:01:22 -0400, Garrett Wollman: [...] > >> Nobody knows what f_fsid is supposed to contain (but see below). > > Actually, it is quite well known (just apparently not by the author of > that document). The fsid is used to generate NFS file handles. It's > supposed to be random and

Re: Testing if two files are on the same file system

2017-10-24 Thread Garrett Wollman
< said: > 2017-10-24 09:06:19 -0700, Nick Stoughton: >> > If you are correct, this is a Linux kernel bug. >> >> Why? The stat command is not standardized. The --file-system argument >> changes the output of %i to something other than the inode ... no bug. > [...] > Actually, the Linux man page

Re: Testing if two files are on the same file system

2017-10-24 Thread Joerg Schilling
Nick Stoughton wrote: > > If you are correct, this is a Linux kernel bug. > > Why? The stat command is not standardized. The --file-system argument > changes the output of %i to something other than the inode ... no bug. Whether it is standardized or not, it prints

Re: Testing if two files are on the same file system

2017-10-24 Thread Stephane Chazelas
2017-10-24 10:22:42 +0100, Stephane Chazelas: [...] > stat implementations > [...] > Only the zsh stat builtin (can be loaded as > "zstat" to avoid overriding the system's stat for those that now > have added (an incompatible) one since) can avoid the fork (if > performance is

Re: Testing if two files are on the same file system

2017-10-24 Thread Stephane Chazelas
2017-10-24 09:06:19 -0700, Nick Stoughton: > > If you are correct, this is a Linux kernel bug. > > Why? The stat command is not standardized. The --file-system argument > changes the output of %i to something other than the inode ... no bug. [...] Actually, the Linux man page for statfs(2)

Re: Testing if two files are on the same file system

2017-10-24 Thread Nick Stoughton
> If you are correct, this is a Linux kernel bug. Why? The stat command is not standardized. The --file-system argument changes the output of %i to something other than the inode ... no bug. -- Nick On Tue, Oct 24, 2017 at 2:26 AM, Joerg Schilling < joerg.schill...@fokus.fraunhofer.de> wrote:

Re: Testing if two files are on the same file system

2017-10-24 Thread Andries E. Brouwer
On Tue, Oct 24, 2017 at 10:22:42AM +0100, Stephane Chazelas wrote: > 2017-10-21 12:39:25 +0200, Andries E. Brouwer: > > On Sat, Oct 21, 2017 at 09:26:04AM +0100, Geoff Clare wrote: > > > > > Linux allows two mounts to the same mount point. (I tested it with > > > "mount --bind ..."; not sure if

Re: Testing if two files are on the same file system

2017-10-24 Thread Joerg Schilling
Stephane Chazelas wrote: > However if "dir" is (was) ".", the inode of "." will stay > unchanged (the cwd case you mentioned). > > /tmp/1$ sudo mount -t tmpfs x $PWD > /tmp/1$ ls -id . $PWD > 311402 . 2 /tmp/1 > $ df -P . $PWD > Filesystem

Re: Testing if two files are on the same file system

2017-10-24 Thread Joerg Schilling
Vincent Lefevre wrote: > as with "stat --file-system --format=%i", the output is 0 for any file > on a tmpfs. If you are correct, this is a Linux kernel bug. The original tmpfs implementation on Solaris does not have this problem. Jörg -- EMail:jo...@schily.net

Re: Testing if two files are on the same file system

2017-10-24 Thread Stephane Chazelas
2017-10-21 12:39:25 +0200, Andries E. Brouwer: > On Sat, Oct 21, 2017 at 09:26:04AM +0100, Geoff Clare wrote: > > > Linux allows two mounts to the same mount point. (I tested it with > > "mount --bind ..."; not sure if it would work with a "real" mount.) > > However, the files in the first mount

Re: Testing if two files are on the same file system

2017-10-23 Thread Vincent Lefevre
On 2017-10-18 17:27:04 +0200, Joerg Wunsch wrote: > As Wheeler, David A wrote: > > > It's not just spaces. Filesystem names may contain newlines and > > other control characters, too, so "df -P" is fundamentally unsafe. > > Well, it's a question of whether your goal is to be always on the >

Re: Testing if two files are on the same file system

2017-10-21 Thread Andries E. Brouwer
On Sat, Oct 21, 2017 at 09:26:04AM +0100, Geoff Clare wrote: > Linux allows two mounts to the same mount point. (I tested it with > "mount --bind ..."; not sure if it would work with a "real" mount.) > However, the files in the first mount are inaccessible until the > second is unmounted, so

Re: Testing if two files are on the same file system

2017-10-21 Thread Joerg Schilling
> Hmm... on Linux, there can be several tmpfs mounts and they all have the > same file system name in the first column. Example: > > tmpfs 33039212 0 33039212 0% /dev/shm > tmpfs 33039212 3277180 29762032 10% /run > tmpfs 5120 0 5120 0% /run/lock > tmpfs 33039212 0

Re: Testing if two files are on the same file system

2017-10-21 Thread Geoff Clare
Martijn Dekker wrote, on 21 Oct 2017: > > Op 19-10-17 om 15:06 schreef Martijn Dekker: > > Op 18-10-17 om 16:11 schreef Geoff Clare: > >> After the filesystem name there are four numeric fields with a trailing '%' > >> on the fourth. Treating this as the terminator for the

Re: Testing if two files are on the same file system

2017-10-19 Thread Martijn Dekker
Op 19-10-17 om 15:14 schreef Joerg Wunsch: > As Martijn Dekker wrote: > >> There is another, less unlikely problem, though: a file system could be >> mounted on a directory with a name containing a newline, which would >> break line-based parsing. > > Pipe the output of df -P through "tail -n +2

Re: Testing if two files are on the same file system

2017-10-19 Thread Joerg Wunsch
As Martijn Dekker wrote: > There is another, less unlikely problem, though: a file system could be > mounted on a directory with a name containing a newline, which would > break line-based parsing. Pipe the output of df -P through "tail -n +2 | head -1". :-) That way, you don't have to care

Re: Testing if two files are on the same file system

2017-10-19 Thread Martijn Dekker
Op 19-10-17 om 13:12 schreef Joerg Schilling: > No, the first field usually is the background storage, it may be the filesytem > name in some cases. Whatever it technically may be, the POSIX spec calls it a file system name, so I'm using that term to be consistent with it.

Re: Testing if two files are on the same file system

2017-10-19 Thread Martijn Dekker
Op 18-10-17 om 16:11 schreef Geoff Clare: > After the filesystem name there are four numeric fields with a trailing '%' > on the fourth. Treating this as the terminator for the filesystem name > ought to be good enough in practice. It would only not work in the > extremely unlikely event that a

Re: Testing if two files are on the same file system

2017-10-19 Thread Geoff Clare
Joerg Schilling wrote, on 19 Oct 2017: > > You need to look at the 2nd line and you may use the '%' sign to synchronize > fields and you may even do this: > > /usr/xpg4/bin/df -P /etc/passwd /etc/hosts > Dateisystem 512-Blöcke Belegt

Re: Testing if two files are on the same file system

2017-10-19 Thread Joerg Schilling
Martijn Dekker wrote: > Is there a way, using POSIX shell and utilities, to reliably test if two > files are on the same file system? It seems like a basic feature that > the shell should have access to, so I'd like to add it to the modernish > shell library. > > The only POSIX

RE: Testing if two files are on the same file system

2017-10-18 Thread Wheeler, David A
Joerg Wunsch [mailto:aus...@uriah.heep.sax.de]: > Unlike a filename, a filesystem name is nothing that could be invented by > Mr. Malicious User, so if the only point is to handle OSX as well as (say) > Linux, BSD, Solaris etc. the pragmatic way that has been posted might > suffice. My mistake.

Re: Testing if two files are on the same file system

2017-10-18 Thread Joerg Wunsch
As Wheeler, David A wrote: > It's not just spaces. Filesystem names may contain newlines and > other control characters, too, so "df -P" is fundamentally unsafe. Well, it's a question of whether your goal is to be always on the safe side, or just pragmatically to cope with a number of really

Re: Testing if two files are on the same file system

2017-10-18 Thread Geoff Clare
Joerg Wunsch wrote, on 18 Oct 2017: > > As Martijn Dekker wrote: > > > Is there a way, using POSIX shell and utilities, to reliably test if two > > files are on the same file system? > > df -P appears to be required to have the filesystem name as the first > column.

Re: Testing if two files are on the same file system

2017-10-18 Thread Joerg Wunsch
As Martijn Dekker wrote: > Is there a way, using POSIX shell and utilities, to reliably test if two > files are on the same file system? df -P appears to be required to have the filesystem name as the first column. Filesystem names with a space however might be a problem, at least if they