fopen() 返回 NULL 指针,但文件确实存在

发布于 2024-11-19 19:43:13 字数 291 浏览 2 评论 0原文

我的代码如下:

FILE *txt_file = fopen("data.txt", "r");
if (txt_file == NULL) {
    perror("Can't open file");
} 

返回的错误信息是:

无法打开文件:没有这样的文件或目录

文件“data.txt”肯定存在于工作目录中(它存在于包含我的 .c 和 .h 文件的目录中),那么为什么 fopen() 返回一个空指针?

The code I have is as follows:

FILE *txt_file = fopen("data.txt", "r");
if (txt_file == NULL) {
    perror("Can't open file");
} 

The error message returned is:

Can't open file: No such file or directory

The file 'data.txt' definitely exists in the working directory (it exists in the directory that contains my .c and .h files), so why is fopen() is returning a NULL pointer?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

栀子花开つ 2024-11-26 19:43:13

标准问题。尝试

FILE *txt_file = fopen("C:\\SomeFolder\\data.txt", "r");

即尝试先使用完整绝对路径打开它;如果它有效,那么您只需使用 _getcwd() 找出当前目录是什么,然后修复您的相对路径。

Standard problem. Try

FILE *txt_file = fopen("C:\\SomeFolder\\data.txt", "r");

I.e. try opening it with the full absolute path first ; if it works then you just have to figure out what the current directory is with _getcwd() and then fix your relative path.

Bonjour°[大白 2024-11-26 19:43:13

文件名有可能不是真正的“data.txt”吗?

在 Unix 上,文件名实际上是字节字符串而不是字符串,并且可以创建名称中带有诸如退格键之类的控件的文件。我过去见过这样的情况:复制粘贴到终端会产生具有普通名称的文件,但尝试打开目录列表中出现的文件名会导致错误。

确定文件名是否如您所想的一种方法是:

$ python
>>> import os
>>> os.listdir('.')

Is it possible that the filename is not really "data.txt"?

On Unix, filenames are really byte strings not character strings, and it is possible to create files with controls such as backspace in their names. I have seen cases in the past in which copy-pasting into terminals resulted in files with ordinary-looking names, but trying to open the filename that appears in a directory listing results in an error.

One way to tell for sure that the filenames really are what you think they are:

$ python
>>> import os
>>> os.listdir('.')
懒的傷心 2024-11-26 19:43:13

我的问题是我有一个文件 filename.txt,但我没有意识到实际上它是 filename.txt.txt,因为 Windows 没有显示扩展名。

My problem was that I had a file filename.txt and I didn't realize that in reality it was filename.txt.txt due to windows not showing the extension.

我要还你自由 2024-11-26 19:43:13

确保您的输入文件与可执行文件位于同一目录中,该目录可能与保存源文件的目录不同。如果您在 IDE 调试器中运行程序,请确保您的工作目录设置为输入文件的位置。另外,如果您在 *nix 而不是 Windows 中运行,则可能需要在输入文件名前添加“./”。

Make sure that your input file is in the same directory as the executable, which may be different than the one where your source files are kept. If you're running the program in an IDE debugger, make sure that your working directory is set to the location of the input file. Also, if you're running in *nix rather than Windows, you may need to prepend a "./" to the input filename.

神仙妹妹 2024-11-26 19:43:13

文件名中的空格字符不可见?

每年我都会遇到类似的问题:
我尝试打开一个文件,该文件的文件名是从字符串操作中获得的字符串。当我打印名称时,看起来没问题,但 fopen() 返回一个空指针。唯一的帮助是打印带有分隔符的名称,显示文件名字符串的确切开头和结尾。当然,这对不可打印的字符没有帮助。

Invisible SPACE character in file name?

Once a year I have a similar problem:
I try to open a file with the filename in a string, obtained from a sting operation. When I print the name it seems OK, but fopen() returns a null pointer. The only help is printing the name with delimiters showing the exact beginning and end of the filename string. Of course this does not not help with unprintable chars.

ペ泪落弦音 2024-11-26 19:43:13

我刚刚遇到了类似的问题,我知道路径是正确的并且文件位于正确的位置。检查文件权限。该程序可能无法访问该文件,因为它的权限被拒绝。

I just had a similar issue like this where I knew the path was correct and the file was in the right location. Check the file permissions. It is possible that the program cannot access the file because it is getting permission denied.

寻找我们的幸福 2024-11-26 19:43:13

我在 Linux 上从 Windows 损坏的脚本文件中 fopen 时遇到了相同的 errno。

ENOENT 2

Windows 上没有这样的文件或目录写字板(或其他一些 Microsoft 罪魁祸首)将 CRLF = (0x0D, 0x0A) 插入我的 Linux 脚本文件中,代替换行符 = LF = 0x0A。当我将文件名读入缓冲区并调用 fopen 时(如果由于附加的不可见 CR 字符而失败)。

在 Linux Mint 上的 Codelite 编辑器中,我能够显示 EOL 字符(“查看”>“显示 EOL”),并通过查找和替换来删除它们,方法是将损坏的脚本文件中的 CRLF 和未损坏文件中的 LF 复制并粘贴到文本字段。

I encountered the same errno to fopen on Linux from a script file corrupted by Windows.

ENOENT 2 No such file or directory

Wordpad on Windows (or some other Microsoft culprit) inserted CRLF = (0x0D, 0x0A) into my linux script files in place of newline = LF = 0x0A. When I read the file name into a buffer and called fopen if failed due to the invisible appended CR character.

In the Codelite editor on Linux Mint I was able to show EOL characters (View > Display EOL) and remove them with find and replace, using copy and paste of the CRLF from the corrupted script files and the LF from an uncorrupted file into the text fields.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文