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

iOS file size during write using only C/C++ APIs

本文关键字：文件大小 iOS C++API      更新时间：2023-10-16

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

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

失败的解决方案：

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

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

  3. 我还尝试过使用stat（）和st_mtimespec修改日期而不是大小，并且在写入过程中日期似乎没有改变——这不是我所期望的

回到NSFileManager为我提供正确值的能力，有人知道[NSFileManager attributesOfItemAtPath:]在下面实际使用的C API调用吗？

提前谢谢。

更新：这似乎与正在进行的写入操作无关，而与特定文件有关。经过仔细检查，有些文件总是返回大小，而其他文件在使用C API时从不返回大小（但使用Objective-C API会很好）。即使创建一个"好"文件的副本，C API也不想给出副本的大小，但可以很好地处理原始"好"的文件。我在文本（xml）文件和二进制（zip）文件方面既有失败也有成功。我正在使用iTunes将这些文件添加到iPad应用程序的Documents目录中。这是一台iPad Mini Retina。

更新2-答案：如果你的路径没有像我的路径那样被无形地破坏，那么上面任何一种文件大小的方法都可能有效。查看关于路径被破坏的原因的公认答案。

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

错误的路径连接：显然（或者在运行时不那么明显）str复制三次以上不会有好的结果。

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

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

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

长话短说，由于两个拼写错误，我的工作很草率。

相关文章：