Question

目的：我正在使用BSD内核队列监视iOS上特定目录中的文件写入，并轮询文件大小以确定写入结束（当大小停止更改时）。基本思路是在来自iTunes同步的任意数量的文件副本之后仅刷新文件夹。我有一个完全有效的Objective-C实现，但我有理由需要在C ++中实现相同的东西。

问题：阻止我的一件事是我无法找到在写入期间获得正确文件大小的C或C ++ API。据推测，必须存在一个因为Objective-C的[NSFileManager attributesOfItemAtPath：]似乎工作，我们都知道它只是在下面调用一个C API。

解决方案失败：

我已经尝试使用stat（）和lstat（）获取st_size甚至st_blocks来获取已分配的块数，并且它们为目录中的大多数文件返回正确的大小，但是当文件写入时发生了该文件的大小永远不会在轮询间隔之间发生变化，并且在该目录中迭代的每个后续文件的大小都不正确。

我尝试过使用fseek和ftell，但它们也导致了一个非常类似的问题。

我还尝试使用stat（）和st_mtimespec修改日期而不是大小，并且在写入期间日期似乎没有变化 - 不是我期望的那样。

回到NSFileManager为我提供正确值的能力，有没有人知道[NSFileManager attributesOfItemAtPath：]实际使用的C API调用是什么？

提前致谢。

更新看起来这与正在进行的写操作有关，而与特定文件有关。经过仔细检查后，有些文件总是返回一个大小，而其他文件在使用C API时永远不会返回大小（但可以与Objective-C API一起使用）。即使创建“好”文件的副本，C API也不希望为副本提供大小，但可以使用原始的“好”文件。我有文本（xml）文件和二进制（zip）文件的失败和成功。我正在使用iTunes将这些文件添加到iPad的应用程序的Documents目录中。这是一款iPad Mini Retina。

更新2 - 答案： 如果你的路径没有像我的那样被无形地删除，那么上述任何文件大小的方法都可能有效。有关路径被破坏的原因，请参阅已接受的答案。

Answer 1

这个奇怪的行为结果证明是路径的问题，导致字符串会正常打印，但很可能在内存中被破坏，文件描述符有时不喜欢它（因此只发生在某些情况下）文件路径）。我使用dirent API迭代目录中的文件并错误地连接dir路径和文件名。

错误路径连接：显然（或在运行时显然不那么明显）str-copy三次复制并不会很好。

char* fullPath = (char*)malloc(strlen(dir) + strlen(file) + 2);
strcpy(fullPath, dir);
strcpy(fullPath, "/");
strcpy(fullPath, file);
long sizeBytes = getSize(fullPath);
free(fullPath);

正确的路径连接：使用正确的str-concatenation。

char* fullPath = (char*)malloc(strlen(dir) + strlen(file) + 2);
strcpy(fullPath, dir);
strcat(fullPath, "/");
strcat(fullPath, file);
long sizeBytes = getSize(fullPath);
free(fullPath);

长话短说，通过两个错别字，我的工作很草率。

仅使用C / C ++ API进行写入时的iOS文件大小

1 个答案: