How to uniquely identifity a file?

[alberthsu_1]

I have a file, say named "A". If somebody removed the original file "A", and then re-created another "A" file, how will I be able to know that? Is there anything like file ID that I can uniquely identify a file?

(The file will be modified frequently, so I cannot use file update time for the purpose.)

[Joseph C. Denman]

How about the date/time stamp?
File size?


...jcd...

[Patrick Wallek]

That depends on where the file is moved.

Let's take your example with a file named 'A' and the file is in the directory /Alpha. If someone moves the file to A.bak, but it is still in the directory /Alpha then the you can use the inode number of the file. You can see the inode number by doing an 'ls -i A' or 'll -i A'. Here is an example:

# touch A
[uran:root] 515 /tmp
# ll -i A
194 -rw-rw-r-- 1 root sys 0 Jul 9 09:51 A
[uran:root] 516 /tmp
# mv A A.bak
[uran:root] 517 /tmp
# touch A
[uran:root] 518 /tmp
# ll -i A*
195 -rw-rw-r-- 1 root sys 0 Jul 9 09:51 A
194 -rw-rw-r-- 1 root sys 0 Jul 9 09:51 A.bak

You will notice that A.bak kept its original inode # of 194 even after it was moved.


If the file is moved to a different directory, and that directory is in a different Logical Volume, then the inode number will change, and I don't know how you could keep track of the file that way.

Does this help?

[someone_4]

if every user has their own user name with their own user id. run the ls -l and you will see who owns that file. You can also set permissions using chmod so the file cant be seen or deleted.

Richard

[James R. Ferguson]

Hi:

There are a few indicators of the action that you describe, but none will provide absolute assurance.

1. Every file has a unique 'inode' number within a filesystem (mountpoint). The number can be seen with 'ls -i . However, a file can be created, removed, and created again and, depending on other activity in the filesystem, have the same or a different inode number.

2. If a file is modified (permissions changed, deleted and recreated) then 'ls -lc' will indicate an altered timestamp (see "man ls"). HOWEVER, the problem with looking at this timestamp, is that backup utilities like 'fbackup' will reset the lastaccess timestamp and therefore alter the last inode change timestamp too which is what 'ls -lc; reports.

3. Assuming that the file in question has been deleted and recreated, but slightly differently, then the best indictator of change would be a different checksum (see "man cksum") for the file. This assumes, of course, that you recorded the original checksum somewhere for comparison.

Regards!

...JRF...

[A. Clay Stephenson]

Hi,

This one is tricky. Patrick's idea of inode number works somewhat but it not foolproof. If someone removed the file and then recreated it there is a very chance that the same inode would be reused. All the date/timestamp fields associated with the file can be manipulated.
The only sure method would be to encode unique data within the file itself. If you have access to the code, you could insert a timestamp or other data in the first few bytes of the file. If not (and the file does not grow with time), you could append data to the file which hopefully you application will ignore.

Perhaps the best method is to ensure that the problem does not occur by restricting permissions on the directory and perhaps setting the sticky bit on the directory so that only the file or directory owner can remove the file.

Food for thought, Clay

[Vincenzo Restuccia]

See man cksum and sum.

[Patrick Wallek]

If the file is removed, then the inode # does become a real issue, because, as said above, the file can be removed, then recreated and have the same inode #. When I first read the question I just saw "moved" not "removed". Oops!

[MANOJ SRIVASTAVA]

Hi Alberthsu

Actually that give me an idea . If you really can then do a ls -li and store the inode no. of the file any other file created will be of differnet inode no .This will be good since files have unique id nos.

Manoj Srivastava

[Bill Thorsteinson]

I would answer an unqualified it depends.

The inode number will only be unique among files that
currently exist. Much like phone numbers, once
you give up the inode (delete the file) it may eventually
be reused. Also inode numbers are only unique within a
logical file system. Again to compare to phone numbers
an inode would be like the last four digit which are
unique within an exchange, but are used by several
exchanges. The inode won't change if you move the
file within a file system, but likely will if you move it
to another file system.

As noted the dates can be changed (see man touch).
If I wanted to hide the fact I had replaced your file,
I could always truncate and overwrite the existing
file. Same inode, and I can reset the timestamps, or
on some systems access the raw drive and hide
the file change entirely.

Checksums work if the file doesnt change. If the
file changes then checksums won't work. Checksums
are not necessarily unique.

[Wodisch]

Hell Albert,

you will have to go for a solution a'la "tripwire"!

HTH,
Wodisch

[Robin Wakefield]

If you can afford to have some unwanted files lying around, you could, say, create a hard link to file "A" at its creation time. That way is someone removes "A", the inode will not be freed up. This link name could contain the date/time, for instance.
Next time "A" is created, it will definitely have a different inode - again create a new hard link.

As I say, you're tying up inodes, but you'll be able to tell if "A" has changed.

Robin