c++ - 仅使用 C/C++ API 写入期间的 iOS 文件大小

Question

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

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

失败的解决方案:

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

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

3. 我还尝试使用 stat() 和 st_mtimespec 修改日期而不是大小，并且日期在写入过程中似乎没有发生变化 - 出乎我的意料。

回到 NSFileManager 给我正确值的能力，有没有人知道 [NSFileManager attributesOfItemAtPath:] 在下面实际使用的是什么 C API 调用？

提前致谢。

更新:看起来这与正在进行的写入操作关系不大，而与特定文件关系更大。仔细检查后，有些文件总是返回大小，而其他文件在使用 C API 时从不返回大小(但可以与 Objective-C API 一起正常工作)。即使创建“好”文件的拷贝，C API 也不想为拷贝提供大小，但可以很好地处理原始“好”文件。我对文本 (xml) 文件和二进制 (zip) 文件既有失败也有成功。我正在使用 iTunes 将这些文件添加到 iPad 应用程序的文档目录中。这是 iPad Mini Retina。

更新 2 - 答案:如果您的路径没有像我的那样被无形地破坏，那么上述任何一种文件大小方法都可能会起作用。请参阅已接受的答案，了解路径为何被丢弃。

Answer 1

好吧，这种奇怪的行为原来是路径问题，这导致字符串可以正常打印，但很可能在内存中被大量丢弃，以至于文件描述符有时不喜欢它(因此只发生在某些文件路径中).我使用 dirent API 循环访问目录中的文件并错误地连接目录路径和文件名。

错误的路径串联:显然(或者在运行时显然不太明显)str 复制超过 3 次不会有好的结果。

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

正确的路径连接:使用正确的字符串连接。

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

长话短说，这是我的工作草率，有两个错别字。