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
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
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.
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
> > >
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"
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
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
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
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
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
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
< 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
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
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
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)
> 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:
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
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
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
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
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
>
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
> 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
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
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
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
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.
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
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
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
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.
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
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.
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
34 matches
Mail list logo