Deciding whether two files are the same

[SzH]

Suppose that there is a program that takes two files as its command
line arguments. Is there a (cross platform) way to decide whether the
two files are the same? Simple string comparison is not enough as the
two files might be specified as "file.txt" and "./file.txt", or one of
them may be a symlink to the other.

[I've already posted this 30 min ago but it didn't show up in Google
Groups---sorry if some people get it twice.]

[Victor Bazarov]

SzH wrote:

Suppose that there is a program that takes two files as its command
line arguments. Is there a (cross platform) way to decide whether the
two files are the same? Simple string comparison is not enough as the
two files might be specified as "file.txt" and "./file.txt", or one of
them may be a symlink to the other.

What does it mean for two files to be "the same"? The same contents?
The same size? The same type? The same name? The same partial path?
The same owner? The same permissions? There is no definition of
"same" in C++ beyond "same object" when speaking of to what pointers
point. *You* need to define "same" when it comes to "files".

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Inquirer]

I guess SzH meant paths.
I have the same question. There is something like this in .NET
Framework(Path.Equals)
but I cannot find in Win32 API or any standard libs:(

[Michael Rohan]

On Jan 24, 9:27 am, "Victor Bazarov" <[e-mail]:

SzH wrote:

Suppose that there is a program that takes two files as its command
line arguments. Is there a (cross platform) way to decide whether the
two files are the same? Simple string comparison is not enough as the
two files might be specified as "file.txt" and "./file.txt", or one of
them may be a symlink to the other.

What does it mean for two files to be "the same"? The same contents?
The same size? The same type? The same name? The same partial path?
The same owner? The same permissions? There is no definition of
"same" in C++ beyond "same object" when speaking of to what pointers
point. *You* need to define "same" when it comes to "files".

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Hi,

Given the example in the original post, I believe the "realpath"
function on
Unix should be of use here. It will resolve symlinks, etc, giving the
real
path to the file. Two file paths resolve to the same file if the real
paths
are the same.

Take care,
Michael.

[Inquirer]

and what would that be in Windows? anybody knows?:)

[Victor Bazarov]

Inquirer wrote:

and what would that be in Windows? anybody knows?:)

Somebody in a Windows programming newsgroup might... Here
we don't discuss platform-specific functionality, sorry.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Eric.Malenfant]

On Jan 24, 12:01 pm, SzH <[e-mail]:

Suppose that there is a program that takes two files as its command
line arguments. Is there a (cross platform) way to decide whether the
two files are the same? Simple string comparison is not enough as the
two files might be specified as "file.txt" and "./file.txt", or one of
them may be a symlink to the other.

Out of curiosity, I looked in Boost.Filesystem.

You may be interested in the "equivalent()" function:
http://www.boost.org/libs/filesystem...cate-functions

[mike3]

On Jan 24, 10:27 am, "Victor Bazarov" <[e-mail]:

SzH wrote:

Suppose that there is a program that takes two files as its command
line arguments. Is there a (cross platform) way to decide whether the
two files are the same? Simple string comparison is not enough as the
two files might be specified as "file.txt" and "./file.txt", or one of
them may be a symlink to the other.

What does it mean for two files to be "the same"? The same contents?
The same size? The same type? The same name? The same partial path?
The same owner? The same permissions? There is no definition of
"same" in C++ beyond "same object" when speaking of to what pointers
point. *You* need to define "same" when it comes to "files".

Based on his example it looks like he wants to know if two given
references refer to the same file.

[mike3]

On Jan 24, 10:58 am, "Victor Bazarov" <[e-mail]:

Inquirer wrote:

and what would that be in Windows? anybody knows?:)

Somebody in a Windows programming newsgroup might... Here
we don't discuss platform-specific functionality, sorry.

However, the original poster asked about cross-platform methods.
Do any exist?

[Victor Bazarov]

mike3 wrote:

On Jan 24, 10:58 am, "Victor Bazarov" <[e-mail]:

>Inquirer wrote:

>>and what would that be in Windows? anybody knows?:)

Somebody in a Windows programming newsgroup might... Here
we don't discuss platform-specific functionality, sorry.

However, the original poster asked about cross-platform methods.
Do any exist?

Cross which platforms? Not all platforms have files.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[SzH]

On Jan 24, 6:27 pm, "Victor Bazarov" <[e-mail]:

SzH wrote:

Suppose that there is a program that takes two files as its command
line arguments. Is there a (cross platform) way to decide whether the
two files are the same? Simple string comparison is not enough as the
two files might be specified as "file.txt" and "./file.txt", or one of
them may be a symlink to the other.

What does it mean for two files to be "the same"? The same contents?
The same size? The same type? The same name? The same partial path?
The same owner? The same permissions? There is no definition of
"same" in C++ beyond "same object" when speaking of to what pointers
point. *You* need to define "same" when it comes to "files".

I meant the following definition of "same": Two files are the same if
when one is changed (e.g. written to), the other changes too. I did
not mean two files with the same content, but the same physical file
on the hard disk.

Suppose that we have a utility that reads from one file and writes to
the other. If by accident the same output file is used for both input
and output, then the contents of the file might get deleted, and the
data might be lost ... A simple check is to compare the file names,
but as I explained in the original message, this is not reliable.

[SzH]

On Jan 24, 10:16 pm, "Victor Bazarov" <[e-mail]:

mike3 wrote:

On Jan 24, 10:58 am, "Victor Bazarov" <[e-mail]:

Inquirer wrote:
and what would that be in Windows? anybody knows?:)

Somebody in a Windows programming newsgroup might... Here
we don't discuss platform-specific functionality, sorry.

However, the original poster asked about cross-platform methods.
Do any exist?

Cross which platforms? Not all platforms have files.

Cross those platforms which do have files and one can use
std::ofstream file(path_to_file); ?

[darko.trpceski]

On Jan 24, 12:01*pm, SzH <[e-mail]:

Suppose that there is a program that takes two files as its command
line arguments. *Is there a (cross platform) way to decide whether the
two files are the same? *Simple string comparison is not enough as the
two files might be specified as "file.txt" and "./file.txt", or one of
them may be a symlink to the other.

[I've already posted this 30 min ago but it didn't show up in Google
Groups---sorry if some people get it twice.]

This might have some logical solution.
I would imagine that if you open the file in "exclusive-write" mode
and try to open the other one you can check if the files are the same.

[Jerry Coffin]

In article <a12780a6-8cdc-4cc2-9c30-860538ea2493
@x69g2000hsx.googlegroups.com>, sd******@gmail.com says...

and what would that be in Windows? anybody knows?:)

If you ask about GetFullPathName somehwere like comp.os.ms-
windows.programmer.win32, chances of getting useful help will be much
better.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[James Kanze]

On Jan 24, 6:44 pm, Michael Rohan <[e-mail]:

On Jan 24, 9:27 am, "Victor Bazarov" <[e-mail]:

SzH wrote:

Suppose that there is a program that takes two files as its command
line arguments. Is there a (cross platform) way to decide whether the
two files are the same? Simple string comparison is not enough as the
two files might be specified as "file.txt" and "./file.txt", or one of
them may be a symlink to the other.

What does it mean for two files to be "the same"? The same contents?
The same size? The same type? The same name? The same partial path?
The same owner? The same permissions? There is no definition of
"same" in C++ beyond "same object" when speaking of to what pointers
point. *You* need to define "same" when it comes to "files".

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Hi,

Given the example in the original post, I believe the "realpath"
function on
Unix should be of use here. It will resolve symlinks, etc, giving the
real
path to the file. Two file paths resolve to the same file if the real
paths
are the same.

Take care,
Michael.

[James Kanze]

On Jan 24, 10:23 pm, SzH <[e-mail]:

On Jan 24, 6:27 pm, "Victor Bazarov" <[e-mail]:

SzH wrote:

Suppose that there is a program that takes two files as
its command line arguments. Is there a (cross platform)
way to decide whether the two files are the same? Simple
string comparison is not enough as the two files might be
specified as "file.txt" and "./file.txt", or one of them
may be a symlink to the other.

What does it mean for two files to be "the same"? The same
contents? The same size? The same type? The same name?
The same partial path? The same owner? The same
permissions? There is no definition of "same" in C++ beyond
"same object" when speaking of to what pointers point.
*You* need to define "same" when it comes to "files".

I meant the following definition of "same": Two files are the
same if when one is changed (e.g. written to), the other
changes too. I did not mean two files with the same content,
but the same physical file on the hard disk.

This has been discussed in comp.std.c++ with regards to #pragma
once. The problem is very, very difficult, if not impossible to
solve in the absolute---you'd have to find out which system is
serving the files, and ask it. And even then, it can be tricky,
since more than one file server can be running on the host.

Suppose that we have a utility that reads from one file and
writes to the other. If by accident the same output file is
used for both input and output, then the contents of the file
might get deleted, and the data might be lost ... A simple
check is to compare the file names, but as I explained in the
original message, this is not reliable.

Two frequent solutions for that problem: refuse to overwrite an
existing file, or always write to a temporary, renaming it when
you're through.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jan 25, 2:32 pm, "Alf P. Steinbach" <[e-mail]:

* James Kanze:

On Jan 24, 10:23 pm, SzH <[e-mail]:

Suppose that we have a utility that reads from one file and
writes to the other. If by accident the same output file is
used for both input and output, then the contents of the file
might get deleted, and the data might be lost ... A simple
check is to compare the file names, but as I explained in the
original message, this is not reliable.

Two frequent solutions for that problem: refuse to overwrite an
existing file, or always write to a temporary, renaming it when
you're through.

That's not really a solution, and I hate programs that do that.

Which one, refusing to overwrite a file that exists, or going
through a temporary. The first is a question of taste. I'll
admit that with shells that offer this feature for redirected
output, I turn it off. But if you're worried about someone
foolishly specifying the same file for input and output, then it
might be appropriate. I use the second a lot, in cases where I
expect to overwrite the input. (But in such cases, either the
program always overwrites the input, or the user tells me
explicitly that he wants to replace the input.)

Not that I have any general solution, either, but consider:

f1 and f2 are two names for the same file (a.k.a. "hardlinks"),

your program writes file ftemp, deletes f1, renames ftemp to f1,

f1 and f2 are now /not/ two names for the same file.

Yes. Hard links introduce any number of such problems. When I
implement such use of a temporary under Unix, I check for them,
and use physical copy.

E.g., in practice, f1 might be "checkable.html" and f2 might be
"runnable.hta" (because W3C validator doesn't like ".hta").

Cheers, & hope this might cause people to think twice before
doing that write-temp-delete-and-rename thing, even if it is a
little off-topic!,

It's a useful remark, however, since we tend to forget. And
I'll bet quite a number of programs don't handle the case
correctly.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Michal Nazarewicz]

>SzH wrote:

>>Suppose that there is a program that takes two files as its command
line arguments. Is there a (cross platform) way to decide whether the
two files are the same? Simple string comparison is not enough as the
two files might be specified as "file.txt" and "./file.txt", or one of
them may be a symlink to the other.

I'd say the only way is to read both files byte-by-byte and compare them.

Michael Rohan <Mi*************@gmail.comwrites:

Given the example in the original post, I believe the "realpath"
function on Unix should be of use here. It will resolve symlinks,
etc, giving the real path to the file. Two file paths resolve to the
same file if the real paths are the same.

It won't resolve hard links.

--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>--<jid:mina86*jabber.org>--ooO--(_)--Ooo--

[Michal Nazarewicz]

>>SzH wrote:

>>>Suppose that there is a program that takes two files as its command
line arguments. Is there a (cross platform) way to decide whether the
two files are the same? Simple string comparison is not enough as the
two files might be specified as "file.txt" and "./file.txt", or one of
them may be a symlink to the other.

Michal Nazarewicz <mi****@tlen.plwrites:

I'd say the only way is to read both files byte-by-byte and compare
them.

Oh.. you mean "the same" not "equal". Then the above approach won't
work since it would give false positives.

--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>--<jid:mina86*jabber.org>--ooO--(_)--Ooo--

[James Kanze]

On Jan 26, 4:07 pm, Pavel <dot_com_yahoo@paultolk_reverse.yourself>
wrote:

SzH wrote:

[...]

On the file systems complying to UNIX conventions (which is
where harlinks are mostly met), you could compare the file
system and inode.

The fact that the file systems are different doesn't mean that
you don't have the same file.

[...]

All this said, even within UNIX conventions you may disguise the
"sameness" of the files (one easy way is to mount the same NFS file
system more than once, addressing it by IPs of different NICs of the
same file server). Difficult to believe but I saw things like this
happening in production IT environment.

I've rarely seen production enviroments where it wasn't the
case. (In one case, a collegue, waiting for a compile, decided
to "clean up" some, and deleted all of the files belonging to
him in /tmp. For reasons related to the way remote backups were
handled, his home directory was also mounted in /tmp. The
results were not very pleasant.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Michal Nazarewicz]

Pavel <dot_com_yahoo@paultolk_reverse.yourselfwrites:

On the file systems complying to UNIX conventions (which is where
harlinks are mostly met), you could compare the file system and
inode. Now, a perfect comparison of file systems is a challenge in
itself but often you can reasonably know the files belong to the same
file system (if they are in the same directory, for example, and not
symlinks).

It's fairly simple. All you have to do is stat(2) the files and compare
st_dev and st_ino fields of stat structure returned by those calls.

--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>--<jid:mina86*jabber.org>--ooO--(_)--Ooo--

[James Kanze]

On Jan 27, 2:24 pm, Michal Nazarewicz <[e-mail]:

Pavel <dot_com_yahoo@paultolk_reverse.yourselfwrites:

On the file systems complying to UNIX conventions (which is where
harlinks are mostly met), you could compare the file system and
inode. Now, a perfect comparison of file systems is a challenge in
itself but often you can reasonably know the files belong to the same
file system (if they are in the same directory, for example, and not
symlinks).

It's fairly simple. All you have to do is stat(2) the files and compare
st_dev and st_ino fields of stat structure returned by those calls.

If they're the same, the files are part of the same file system
(I'm pretty sure). If they're different, you don't know.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Michal Nazarewicz]

James Kanze <ja*********@gmail.comwrites:

On Jan 27, 2:24 pm, Michal Nazarewicz <[e-mail]:

>Pavel <dot_com_yahoo@paultolk_reverse.yourselfwrites:

On the file systems complying to UNIX conventions (which is where
harlinks are mostly met), you could compare the file system and
inode. Now, a perfect comparison of file systems is a challenge in
itself but often you can reasonably know the files belong to the same
file system (if they are in the same directory, for example, and not
symlinks).

>It's fairly simple. All you have to do is stat(2) the files and compare
st_dev and st_ino fields of stat structure returned by those calls.

If they're the same, the files are part of the same file system
(I'm pretty sure). If they're different, you don't know.

If they are different either their inode number or device number
differ. If both inode and device number are the same the files are the
same. The problem is that you don't know if the files are different if
either inode number or device number differ (as it was discussed earlier
on an example of NFS directory mounted using two different IPs).

--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>--<jid:mina86*jabber.org>--ooO--(_)--Ooo--

[James Kanze]

Michal Nazarewicz wrote:

James Kanze <ja*********@gmail.comwrites:

On Jan 27, 2:24 pm, Michal Nazarewicz <[e-mail]:

Pavel <dot_com_yahoo@paultolk_reverse.yourselfwrites:
On the file systems complying to UNIX conventions (which is where
harlinks are mostly met), you could compare the file system and
inode. Now, a perfect comparison of file systems is a challenge in
itself but often you can reasonably know the files belong to the same
file system (if they are in the same directory, for example, and not
symlinks).

It's fairly simple. All you have to do is stat(2) the files and compare
st_dev and st_ino fields of stat structure returned by those calls.

If they're the same, the files are part of the same file system
(I'm pretty sure). If they're different, you don't know.

If they are different either their inode number or device number
differ.

If they differ in their inode number, they are different. If
the device number differs, they might be different, or they
might not be. It's a fairly frequent occurence for the same
file system to be mounted with different inode numbers.

If both inode and device number are the same the files are the
same. The problem is that you don't know if the files are
different if either inode number or device number differ (as
it was discussed earlier on an example of NFS directory
mounted using two different IPs).

That's what I've been saying, and contradicts what you first
said. I think that if the inode numbers are different, the
files are different, but I've seen identical files with
different device numbers.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Pavel]

da************@gmail.com wrote:

On Jan 24, 12:01 pm, SzH <[e-mail]:

>Suppose that there is a program that takes two files as its command
line arguments. Is there a (cross platform) way to decide whether the
two files are the same? Simple string comparison is not enough as the
two files might be specified as "file.txt" and "./file.txt", or one of
them may be a symlink to the other.

[I've already posted this 30 min ago but it didn't show up in Google
Groups---sorry if some people get it twice.]

This might have some logical solution.
I would imagine that if you open the file in "exclusive-write" mode
and try to open the other one you can check if the files are the same.

What is someone else was entertaining herself opening one of the files
in "exclusive-write" mode while we were doing same? :-)

-Pavel

[Jerry Coffin]

In article <5fc93358-28ec-4d62-85d1-134574a6a8d2
@s13g2000prd.googlegroups.com>, ja*********@gmail.com says...

On Jan 27, 2:24 pm, Michal Nazarewicz <[e-mail]:

[ ... ]

It's fairly simple. All you have to do is stat(2) the files and compare
st_dev and st_ino fields of stat structure returned by those calls.

If they're the same, the files are part of the same file system
(I'm pretty sure). If they're different, you don't know.

That depends a bit on viewpoint. Quite a few distributed file systems
provide a situation in which what's logically considered a single file
resides on a number of different machines. I.e. you have one logical
file system living on top of a number of physical file systems (so to
speak).

Such a system normally provides some unambiguous way to identify a file
(necessary for its own bookkeeping) but using it isn't portable. Each
system normally has a proxy entry in its own file system, so comparing
files on that system works just fine -- but two device/inode pairs on
two separate systems might actually refer to the same file so writes to
one will show up when reading the other.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[James Kanze]

On Jan 29, 7:11 am, Jerry Coffin <[e-mail]:

In article <5fc93358-28ec-4d62-85d1-134574a6a8d2
@s13g2000prd.googlegroups.com>, [e-mail] says...

On Jan 27, 2:24 pm, Michal Nazarewicz <[e-mail]:

[ ... ]

It's fairly simple. All you have to do is stat(2) the files and compare
st_dev and st_ino fields of stat structure returned by those calls.

If they're the same, the files are part of the same file system
(I'm pretty sure). If they're different, you don't know.

That depends a bit on viewpoint. Quite a few distributed file systems
provide a situation in which what's logically considered a single file
resides on a number of different machines. I.e. you have one logical
file system living on top of a number of physical file systems (so to
speak).

Such a system normally provides some unambiguous way to identify a file
(necessary for its own bookkeeping) but using it isn't portable. Each
system normally has a proxy entry in its own file system, so comparing
files on that system works just fine -- but two device/inode pairs on
two separate systems might actually refer to the same file so writes to
one will show up when reading the other.

I'm not sure that that's relevant here. Regardless of where the
files reside, you get all of the files below a single mount
point from a single file server. And you can always get the
same files, mounted elsewhere, through a different server, or a
different connection to the same server. Files accessed through
different mount points have different device numbers.

Note that Windows has similar problems. I don't know the
Windows equivalents of inode numbers and device numbers, but you
can certainly mount the same file through different mount
points, either using SMB or using NFS. And as far as I can
tell, the protocols really provide no way of determining where
the file really comes from.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Jerry Coffin]

In article <91b48e6d-cc9e-481c-bb75-
66**********@e6g2000prf.googlegroups.com>, ja*********@gmail.com says...

[ ... ]

I'm not sure that that's relevant here. Regardless of where the
files reside, you get all of the files below a single mount
point from a single file server. And you can always get the
same files, mounted elsewhere, through a different server, or a
different connection to the same server. Files accessed through
different mount points have different device numbers.

In a distributed file system, you generally have several servers that
all carry the same files, and one file might be accessible from a number
of different servers.

In most cases, you have at least some degree of location transparency --
i.e. it'll typically support some sort of path that gets resolved to a
server/file combination by file system itself. In most cases, however,
you can also access those files directly from the individual servers as
well...

Note that Windows has similar problems. I don't know the
Windows equivalents of inode numbers and device numbers, but you
can certainly mount the same file through different mount
points, either using SMB or using NFS. And as far as I can
tell, the protocols really provide no way of determining where
the file really comes from.

Oh, absolutely -- I certainly didn't intend to imply that this was
unique to Unix by any means. I just used Unix terminology because that
was already being used in the thread. The same basic problem can arise
in many different systems, though it's also true that there really
aren't that many different OSes any more -- most of what's left is
Windows and various clones of Unix (and somebody who previously dealt
with substantially different systems could be forgiven for thinking of
Windows as a Unix clone...)

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Michal Nazarewicz]

James Kanze <ja*********@gmail.comwrites:

Michal Nazarewicz wrote:

>James Kanze <ja*********@gmail.comwrites:

On Jan 27, 2:24 pm, Michal Nazarewicz <[e-mail]:
Pavel <dot_com_yahoo@paultolk_reverse.yourselfwrites:
On the file systems complying to UNIX conventions (which is where
harlinks are mostly met), you could compare the file system and
inode. Now, a perfect comparison of file systems is a challenge in
itself but often you can reasonably know the files belong to the same
file system (if they are in the same directory, for example, and not
symlinks).

>It's fairly simple. All you have to do is stat(2) the files and compare
st_dev and st_ino fields of stat structure returned by those calls.

If they're the same, the files are part of the same file system
(I'm pretty sure). If they're different, you don't know.

>If they are different either their inode number or device number
differ.

If they differ in their inode number, they are different. If
the device number differs, they might be different, or they
might not be. It's a fairly frequent occurence for the same
file system to be mounted with different inode numbers.

I'm not saying that's not the case.

>

>If both inode and device number are the same the files are the
same. The problem is that you don't know if the files are
different if either inode number or device number differ (as
it was discussed earlier on an example of NFS directory
mounted using two different IPs).

That's what I've been saying, and contradicts what you first
said. I think that if the inode numbers are different, the
files are different, but I've seen identical files with
different device numbers.

And I've never said anything different.

--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>--<jid:mina86*jabber.org>--ooO--(_)--Ooo--