Markus, On Friday 01 April 2005 05:17, Markus Gaugusch wrote:

On Apr 1, pelibali wrote:

...

Hi,

...

...

By the way I have an interesting '/usr/bin/[' file as well; is this strange name just an accident or it supposed to be like this? And why then this uncommon name?

This is the short name for the "test" command, used like if [ -f /etc/passwd ] ; then echo hi ; fi ^-> Yes, a binary is called at this place! Note: Bash programmers should use [[ ]] because it is an internal command and therefore much faster (and more powerful).

Close, but not quite right. The ordinary test alias, '[', is a BASH built-in. The variant named '[[' has different semantics and is not necessarily interchangeable in all cases, though it may behave identically in some. To wit: % type [ [ is a shell builtin % type [[ [[ is a shell keyword % help [ [: [ arg... ] This is a synonym for the "test" builtin, but the last argument must be a literal `]', to match the opening `['. [[ ... ]]: [[ expression ]] Returns a status of 0 or 1 depending on the evaluation of the conditional expression EXPRESSION. Expressions are composed of the same primaries used by the `test' builtin, and may be combined using the following operators ( EXPRESSION ) Returns the value of EXPRESSION ! EXPRESSION True if EXPRESSION is false; else false EXPR1 && EXPR2 True if both EXPR1 and EXPR2 are true; else false EXPR1 || EXPR2 True if either EXPR1 or EXPR2 is true; else false When the `==' and `!=' operators are used, the string to the right of the operator is used as a pattern and pattern matching is performed. The && and || operators do not evaluate EXPR2 if EXPR1 is sufficient to determine the expression's value.

...

Markus

Randall Schulz

Hi, pelibali wrote:

Hi,

I would have another question in (not so tight) relation to this topic. While checking files/folders on my SUSE 9.1 system, I realized, that many times happens, that there are files with the same size and same md5sum and they are really two separated files. I mean named differently, but stored still in the same folder. Is there a security reason or in fact why is this method better and not just link one to another as e.g. the case is for python-related stuff: -rwxr-xr-x 1 root root 5812 2005-02-05 17:23 /usr/bin/python2.3 lrwxrwxrwx 1 root root 9 2005-03-19 23:29 /usr/bin/python -> python2.3

This is a softlink. -> man ln (option -s)

I would say, it's OK, even that the above files are tiny. But there are several others as:

package 'automake' -rwxr-xr-x 2 root root 220546 2004-11-15 13:04 /usr/bin/automake-1.9 -rwxr-xr-x 2 root root 220546 2004-11-15 13:04 /usr/bin/automake or -rwxr-xr-x 2 root root 20632 2004-11-15 13:04 /usr/bin/aclocal-1.9 -rwxr-xr-x 2 root root 20632 2004-11-15 13:04 /usr/bin/aclocal

These are hardlinks. Also: man ln

And additionally for the following two pairs at least 2Mb could be saved, because they are _big_:

package 'perl' /usr/bin/perl /usr/bin/perl5.8.3

/usr/bin/sperl5.8.3 /usr/bin/suidperl

;) hardlinks too

So the brief question is, why is it better to keep two copies of completely same file?

It _is_ the same file ;) Try to use "ls -i" (This shows the inode number, which shows that these files are identical and only once on the disk ;)

Thank you and have a nice weekend, Pelibali

Read a good book about Linux/UNIX administration. You will find some useful and interesting things! ;)) Cheers, Ingo -- Ingo Börnig <ingo at boernig.de> /"\ \ / ASCII Ribbon Campaign ask for phone or snail mail X against HTML email / \ GPG-Fingerprint: 2F8B DDFB F2A8 155A 206D 2969 F8FB 3C63 2033 BF32

Carlos, On Saturday 02 April 2005 03:10, Carlos E. R. wrote:

...

Quick question:

Is there an easier way to list hardlinks, than comparing inode numbers?

No. Directory entries associate names with inodes (implicitly sharing the same file system device, which accounts for the prohibition on cross-device links). Each reference to a particular inode is a name for the file (or other file system entity). It's not as if one's the "original" or "real" file and the other(s) are the links. They're all coequal names for the same file system entity. This is in contrast to symbolic links, in which there's a fundamental distinction between the (symbolic) link and the target. So the only way to find what names refer to the same inode is to enumerate directory entries and compare inode numbers.

Carlos Robinson

Randall Schulz

Hi Carlos! On Apr 6, 2005, at 4:11 AM, Carlos E. R. wrote:

The Monday 2005-04-04 at 20:03 -0700, Randall R Schulz wrote:

...

On Saturday 02 April 2005 03:10, Carlos E. R. wrote:

...

...

Quick question:

Is there an easier way to list hardlinks, than comparing inode numbers?

No. Directory entries associate names with inodes (implicitly sharing the same file system device, which accounts for the prohibition on cross-device links). Each reference to a particular inode is a name for the file (or other file system entity). It's not as if one's the "original" or "real" file and the other(s) are the links. They're all coequal names for the same file system entity. This is in contrast to symbolic links, in which there's a fundamental distinction between the (symbolic) link and the target.

So the only way to find what names refer to the same inode is to enumerate directory entries and compare inode numbers.

Ah, I see. So it is not easy as well to know if a file somewhere is hardlinked somewhere else, except by comparing all inode entries in all directory lists from the same partition/disk.

No, there's also the link count (see man 3 stat, struct stat->st_nlink), which is displayed e.g. by ls -l.

Do you know of a (brief) description of how a inode fs works, somewhere? I come from Dos; I did study how FAT worked in detail, but unix was out of bounds for me at the time, and later I had no occasion to study ext2 or similar. So, although I have some inkling of what an inode is, I really don't know O:-)

Don't know of a formal description, read the linux source (include/linux/fs.h and fs/inode.c seem like a starting point) ;-) Ciao, Roland -- TU Muenchen, Physik-Department E18, James-Franck-Str. 85747 Garching Telefon 089/289-12592; Telefax 089/289-12570 -- When I am working on a problem I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong. -- R. Buckminster Fuller -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GS/CS/M/MU d-(++) s:+ a-> C+++ UL++++ P-(+) L+++ E(+) W+ !N K- w--- M+ !V Y+ PGP++ t+(++) 5 R+ tv-- b+ DI++ e+++>++++ h---- y+++ ------END GEEK CODE BLOCK------

The Wednesday 2005-04-06 at 08:19 -0400, Dana Hudes wrote:

For a more current view (though inodes are still the basis, the organization of them changes) I highly recommend Sarwar et al, Linux: The Textbook (2002 Addison Wesley). ISBN 0-201-72595-9 .

The subject of Chapter 7 is the filesystem.

I was thinking of online documents at the moment. Paper is for serious things, ie, serious learning - but thanks :-) -- Cheers, Carlos Robinson

Carlos, On Sunday 10 April 2005 15:40, Carlos E. R. wrote:

The Wednesday 2005-04-06 at 13:54 +0200, Roland Kuhn wrote:

...

...

Ah, I see. So it is not easy as well to know if a file somewhere is hardlinked somewhere else, except by comparing all inode entries in all directory lists from the same partition/disk.

No, there's also the link count (see man 3 stat, struct stat->st_nlink), which is displayed e.g. by ls -l.

Ah, I see, I hadn't noticed. Except for directories, it must mean something else. I don't see it in "man ls".

It's not that it means something different, but the range of observed values of the link count is somewhat constrained relative to that for other file system entities. Because of the "." and ".." links and because of the link in the parent directory that gives each directory inode its name, directories always have an inode count of 2 + the number of subdirectories the directory contains. Non-directory file system entities have values greater than or equal to zero. They can only be observed to have count zero when they're being held open or are otherwise in use by some process but have had all their referring directory entries removed (via the "unlink" system call). The fact that a file can be in this sense anonymous (have no directory entry referring to it) but still exist and exist precisely as long as it remains in use by at least one process is the fundamental reason why you can do so much software updating on Linux or Unix systems without having to restart the system. In essence both the old and the new versions of a resource can coexist and the old resource will be reclaimed when the last active use of it concludes.

...

-- Cheers, Carlos Robinson

Randall Schulz

Carlos, On Tuesday 05 April 2005 19:11, Carlos E. R. wrote:

The Monday 2005-04-04 at 20:03 -0700, Randall R Schulz wrote:

...

On Saturday 02 April 2005 03:10, Carlos E. R. wrote:

...

...

Quick question:

Is there an easier way to list hardlinks, than comparing inode numbers?

No. ...

So the only way to find what names refer to the same inode is to enumerate directory entries and compare inode numbers.

Ah, I see. So it is not easy as well to know if a file somewhere is hardlinked somewhere else, except by comparing all inode entries in all directory lists from the same partition/disk.

Precisely. In fact, back in the bad old days when there was just "the Unix file system," there used to be (and probably still is, under a name I don't know) a utility called "ncheck" that would take a device name and an inode number and find all the full path names that referred to that inode. It took forever because it had to walk the directory structure exhaustively looking for references to that inode.

Do you know of a (brief) description of how a inode fs works, somewhere? I come from Dos; I did study how FAT worked in detail, but unix was out of bounds for me at the time, and later I had no occasion to study ext2 or similar. So, although I have some inkling of what an inode is, I really don't know O:-)

I did a little looking. This seems accurate and detailed, at least w.r.t. ext2: http://www.tldp.org/LDP/tlk/fs/filesystem.html. Most of what I could find wouldn't add to the knowledge you already have.

Carlos Robinson

Randall Schulz

Carlos, On Sunday 10 April 2005 15:15, Carlos E. R. wrote:

...

...

... back in the bad old days when there was just "the Unix file system," there used to be (and probably still is, under a name I don't know) a utility called "ncheck" that would take a device name and an inode number and find all the full path names that referred to that inode. It took forever because it had to walk the directory structure exhaustively looking for references to that inode.

I have found this one:

xfs_ncheck - generate pathnames from i-numbers for XFS

DESCRIPTION xfs_ncheck with no -i arguments generates an inode number and pathname list of all files on the given filesystem. Names of directory files are followed by /.. The output is not sorted in any particular order. The filesystem to be examined is specified by the xfs_special argument, which should be the disk or volume device for the filesys­ tem. Filesystems stored in files can also be checked, using the -f flag.

That's it exactly. I'm surprised there aren't counterparts for the other file system formats.

...

Ahh! An inode is simply an structure listing file properties and the list of blocks it occupies. And inodes are grouped in tables, repeating info. How simple!

Good ideas are often simple. And in retrospect, obvious. Coming at them from the perspective of the inventor, it's often not so clear what will work best.

:-)

Perhaps I oversimplify.

In fact, you do not. That's exactly it. Now exactly how you represent the "list of blocks it occupies" and get space and time efficiency and robustness in the face of failure and how you structure the free space index and how you lay out on-disk structures all introduce complications into real-world file system designs and implementations. But the inode table + directory tree structure is the essence of all Unix file systems.

-- Cheers, Carlos Robinson

Randall Schulz

/ 2005-04-12 00:27:49 +0200 \ Carlos E. R.:

The Sunday 2005-04-10 at 16:33 -0700, Randall R Schulz wrote:

...

...

xfs_ncheck - generate pathnames from i-numbers for XFS

[...] That's it exactly. I'm surprised there aren't counterparts for the other file system formats.

Yes, I looked using pin, and it is not there, not in 9.1 nor 7.3. For older versions I would have to search on CDs. Unless the name is different :-?

why ncheck? whats wrong with find . -inum 4711 find . -printf "%i\t%p\n" find . \! -type d -printf "%i\t%p\0" | perl -lp0e 's/\n/\\n/g' | sort or similar? cheers Lars

/ 2005-05-04 00:40:11 +0200 \ Carlos E. R.:

The Thursday 2005-04-14 at 17:20 +0200, Lars Ellenberg wrote:

...

...

Yes, I looked using pin, and it is not there, not in 9.1 nor 7.3. For older versions I would have to search on CDs. Unless the name is different :-?

why ncheck? whats wrong with find . -inum 4711 find . -printf "%i\t%p\n" find . \! -type d -printf "%i\t%p\0" | perl -lp0e 's/\n/\\n/g' | sort or similar?

Er... :-? And... how on earth do you think that could occur to me out of my head? :-p

Worse, when I try to find out what does "find . -inum 4711" means, the command "pinfo find" crashes, and "info find" shows the wrong info page (on SuSE 9.3). For further info, see my email to suse-linux-e.

well. I use man... though, on my suse 9.2, info as well as pinfo does work. this is completely off topice here, but I am bored :-), so find . -inum 4711 answers "which files/directories below the current directory reference inode number 4711" find . -printf "%i\t%p\n" answers "what inodes do all the entries below the current directory reference to?", it prints for each found entry "inode-nr <tab> pathname <newline>" find . \! -type d -links +1 -printf "%i\t%p\0" for each entry that is not a directory and has more than 1 hardlinks (+1 means greater than 1, not greater or equal) the inode number, a tab, and the pathname, with a terminating ascii NUL, so the pathnames may contain even newlines and other strange characters. to sort that by inode number, you can pipe it into "sort -z" (-z for "record separator is NUL, not newline"). or first replace all newlines with the two character escape sequence backslash n, then replace the termination NUL with a real newline, then sort by line (what I did above). to be able to reliably unescape that, you'd actually need to escape the backslash itself, too. so to conveniently and reliably list all files that reference an inode which is referenced more than once, you do my_ncheck() { find "$@" \! -type d -links +1 -printf "%i\t%p\0" | perl -lp0e 's:\\:\\\\:g;s:\n:\\n:g' | sort } to easily see what I mean: mkdir -p try/d1 try/; touch try/d1/{1,2,3,4}; cp -al try/d{1,2} my_ncheck try | perl -pe '/^(\d+)\t/; s/^(\d+)// if $1 eq $l; $l = $1;' 252247 try/d1/1 try/d2/1 252248 try/d1/2 try/d2/2 252249 try/d1/3 try/d2/3 252250 try/d1/4 try/d2/4 if you want to cover a huge directory tree (e.g. full file system), it will take some time, and you want to ... > tmp.dups ; sort < tmp.dups > tmp.dups.sort cheers, Lars Ellenberg

The Saturday 2005-04-02 at 13:10 +0200, I wrote:

Quick question:

Is there an easier way to list hardlinks, than comparing inode numbers?

I have an email in my ISP box, from "Klaus Wachtler", sent direct instead of to the list, which will not be downloaded: Apr 6 03:47:51 nimrodel postfix/smtpd[18303]: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 450 <...@lap3......de>: Sender address rejected: Domain not found; from=<...> proto=ESMTP helo=<localhost>. Being a domain (the envelope from, I guess) that does not exist, I can not even warn him directly. -- Cheers, Carlos Robinson