繁体   English   中英

递归计算Linux C中目录中和目录下的文件数

[英]Count the number of files in, and below a directory in Linux C recursively

我编写了一个函数来计算目录中和目录下的文件数(包括子目录中的文件)。 但是,当我在带有子目录的目录上测试代码时,它总是报告错误说:“无法打开目录:没有这样的文件或目录”。 有什么我可以做的事情吗?

int countfiles(char *root, bool a_flag)//a_flag decide if it including hidden file
{
    DIR *dir;
    struct dirent * ptr;
    int total = 0;
    char path[MAXPATHLEN];
    
    dir = opendir(root); //open root dirctory
    if(dir == NULL)
    {
        perror("fail to open dir");
        exit(1);
    }
    
    errno = 0;
    while((ptr = readdir(dir)) != NULL)
    {
        //read every entry in dir
        //skip ".." and "."
        if(strcmp(ptr->d_name,".") == 0 || strcmp(ptr->d_name,"..") == 0)
        {
            continue;
        }
       
        //If it is a directory, recurse
        if(ptr->d_type == DT_DIR)
        {
            sprintf(path,"%s%s/",root,ptr->d_name);
            //printf("%s/n",path);
            total += countfiles(path, a_flag);
        }
        
        if(ptr->d_type == DT_REG)
        {
            if(a_flag == 1){
            total++;
            }
            else if (a_flag == 0){
                if (isHidden(ptr->d_name) == 0){
                    total++;
                }
            }
        }
    }
    if(errno != 0)
    {
        printf("fail to read dir");
        exit(1);
    }
    closedir(dir);
    return total;
}

有什么我可以让它工作的吗?

当然,很多。 就我个人而言,我会首先为这些东西使用正确的接口,在 Linux 和 POSIXy 系统中应该是nftw() 这将导致程序不仅更短、更有效,而且如果有人重命名同时扫描的树中的目录或文件,则不会那么容易混淆。

程序员几乎从来没有像nftw()scandir()glob()fts 系列函数那样健壮和高效地实现 opendir()/readdir()/closedir() 。 为什么老师们在这个时代仍然坚持使用古老的 *dir() 函数,这让我困惑不已。

如果你因为你的老师不知道 POSIX 而你必须使用 *dir 函数并且希望你使用你在现实生活中不应该使用的接口,那么看看你如何构建新目录的路径:sprintf() 行。 也许甚至将它打印出来( path ),您可能会自己找到修复程序。

即便如此, sprintf()在现实生活中也不是允许的(因为当参数比预期的长时,它会导致静默缓冲区溢出;而在 Linux 中可能会发生这种情况,因为实际上没有固定的限制)路径的长度)。 您应该至少使用snprintf()并检查其返回值是否有溢出,或者在 Linux 中使用动态分配结果字符串的asprintf()

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM