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 be unusable
Jörg
--
EMail:
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 as well, but the origina
2017-10-25 22:50:09 +0100, Martijn Dekker:
[...]
> I think this means 'df' and all other utilities (and even basic libc
> functions like fopen()) are required to follow symlinks given as
> arguments, unless explicitly specified otherwise either by the spec or
> (if a relevant option exists) by the
Op 25-10-17 om 14:40 schreef Stephane Chazelas:
> The behaviour of df on symlinks is unspecified AFAICT
Hmmm...
Base Definitions, 3.381 Symbolic Link:
| A type of file with the property that when the file is encountered
| during pathname resolution, a string stored by the file is used to
| modify
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.
I'
2017-10-25 11:17:56 +0200, Martijn Dekker:
[...]
> I'd like to be able to do something like:
>
> if is onsamefs "$file1" "$file2"; then
> ln "$file2" "$file1"# hard links are possible
Should probably be:
ln -f -- "$file2" "$file1"
--
Stephane
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
> > > changes the output of %i to s
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" "$file1"
| fi
That's just creating a race condition. Much be
Op 24-10-17 om 11:22 schreef Stephane Chazelas:
> using sed on the output of df
> #
>
> the output "df -P" is only specified in the POSIX locale.
That's now how I read the spec at
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/df.html#tag_20_33_10
It says
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 pa
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 ignoring this question
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 ... no bug.
>
> Whether i
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 appropriate privilege.
(This is be
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 the
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 uni
< 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 f
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 st_dev and if this is 0,
the u
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)
(http:
> 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:
>
2017-10-24 11:46:28 +0200, Joerg Schilling:
[...]
> This is caused by a recently mentioned bug in the Linux kernel.
>
> See what happens with the tmpfs original:
>
> mkdir /tmp/tmp
> mount -F tmpfs swap /tmp/tmp
>
> stat /tmp /tmp/tmp/
> File: `/tmp'
> Size: 6327Blocks: 16
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 i
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 512-blocks Used Available Capacit
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(home) Jö
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
FUSE might be used to apply an invented name to a freshly formatted partition,
but I don't see it doing that for an existing one - it would report the name
associated with the partition recognition criteria at mount time. I haven't
looked at the code for it lately, but don't remember it having a
There's a contradiction between
On 2017-10-18 15:01:23 +0200, Martijn Dekker wrote:
> GNU stat (or gstat) makes this trivial: 'stat --file-system --format=%i
> /file/one /file/two' provides two hexadecimal file system identifiers to
> compare. But GNU stat is not standard and nowhere near ubiquito
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
> safe
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 pass
> 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 33
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 filesystem name
> >> ou
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 filesystem name
>> ought to be good enough in practice. It would only n
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 whet
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.
http://pubs.opengroup.or
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 f
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 Verfügbar Kapazität Eingehängt
> auf
> /dev/d
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 command I've found
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. I
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
exi
Joerg Wunsch [mailto:aus...@uriah.heep.sax.de]
> 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 contain a number after the space since that cannot be
> distinguished from the number of blo
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. Filesystem names with a spac
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 contai
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 command I've found so far that identifies the file sy
44 matches
Mail list logo
