Printing Hardlinks of an Inode in C - c

Question

I'm writing a program in C to scan the files in a directory, get its inode number, get the hardlink count and print out the hardlinks. So in printing out the hardlinks, i search files from root and match the files with the same inode. However when i set the path to find the matching inode it does not show any files. On the other hand, if i set the path to the same directory i scanned initially it displays one file as a hardlink. I'm open to any other way to display the hardlinks of an inode.
#include <dirent.h>
#include <stdio.h>
#include <string.h>
#include <sys/stat.h>
#include <sys/types.h>
#include<sys/dir.h>
#include<stdlib.h>
void listFilesRecursively(char *path);
void filter(char *basePath, long inode);
void get_hardLinks(long inode);
int main()
{
// Directory path to list files
char path[100]="../";
listFilesRecursively(path);
return 0;
}
void listFilesRecursively(char *basePath)
{
char path[1000];
struct dirent *dp;
struct stat sb;
DIR *dir = opendir(basePath);
struct dirent **namelist = NULL;
// Unable to open directory stream
if (!dir)
return;
while ((dp = readdir(dir)) != NULL)
{
stat(dp->d_name, &sb);
if (strcmp(dp->d_name, ".") != 0 && strcmp(dp->d_name, "..") != 0)
{
printf("Inode:%lu | %s |%ld \n",(unsigned long)dp-> d_ino, dp->d_name,(long) sb.st_nlink);
strcpy(path, basePath);
strcat(path, "/");
strcat(path, dp->d_name);
listFilesRecursively(path);
get_hardLinks((unsigned long)dp-> d_ino);
}
}
closedir(dir);
}
void filter(char *basePath, long inode){
char path[1000];
struct dirent *dp;
struct stat sb;
DIR *dir = opendir(basePath);
while ((dp = readdir(dir)) != NULL)
{
stat(dp->d_name, &sb);
if (strcmp(dp->d_name, ".") != 0 && strcmp(dp->d_name, "..") != 0 && (unsigned long)dp->d_ino==inode && ((long)sb.st_nlink<=10))
{
printf("----HardLink: Inode:%lu | %s \n",(unsigned long)dp-> d_ino, dp->d_name);
strcpy(path, basePath);
strcat(path, "/");
strcat(path, dp->d_name);
filter("/",inode);
}
}
closedir(dir);
}
void get_hardLinks(long inode){
filter("../",inode);
}

Answer 1

The ASK seems to be
List of allfiles (inode, name, #links), in DFS order
for each file show all hard links
It does not explicitly state how symlink should be handled. Answer assumed they can be ignored (including symlink to other directories, which may result in infinite loops).
The current solution has few problems. The first cause incorrect results when scanning over multiple directories, the other may cause serious performance issues when the number of files goes up.
Implementation issue:
Missing Path: The 'stat' calls in listFilesRecursively and filter just pass the file name. This will cause a lookup in the current directory (pwd). But the files is in directory basepath. Code need to form the full pathname by combining the two with a '/'.
Error checking on all system calls: Not testing on 'stat', 'opendir', etc, will have serious impact on the code on any error - either program crash, partial results, on infinite loops.
Performance:
The function listFilesRecursively(path) is being called for each entry. It should only be called for directory entries. (S_ISDIR on the mode).
The function get_hardLinks is getting called for every file ,but it should only get called for files with more than 1 hard link (st_nlink > 1)
The filter will perform recursive call on any entry. Should restrict recursive calls to directories, same as listFilesRecursively above.
Starting point: the question indicate search should start at root, program is starting all searches at the parent folder.
Also, if this is going to run on a large file system in production, consider the following performance tuning:
If the total number of files in the scanned tree is X, current performance will be O(XX), on IO. Even with above improvements, the performance will be O( KX ), where K is the number of files with hardlinks >1, that will cause a scan.
Alternative implementation will perform
Single scan (O(n), remember the i-nodes of all files with hardlinks>1 in dynamically resized array
Sort the array by inodes
Print the files with identical hardlinks from memory.
This will be O(n) for IO, and O(n log n) for sorting. Practically O(n) because IO will dominate the calls. Much faster the current logic.