bun
bun copied to clipboard
Bun.file(path).text() throws error: EBADF
What version of Bun is running?
v0.2.2
What platform is your computer?
Linux 5.4.119-1-tlinux4-0010.1 #1 SMP Thu Aug 25 10:21:45 CST 2022 x86_64 x86_64
What steps can reproduce the bug?
create a file "test.js" with the following:
// test.js
console.log(await Bun.file("./test.txt").text())
and a "test.txt" file with anything, eg:
// test.txt
hello
How often does it reproduce? Is there a required condition?
always.
What is the expected behavior?
open the file "test.txt" and output the content of it.
What do you see instead?
error: EBADF
path: "./test.js"
syscall: "open"
Additional information
it seems the same code works on MacOS (with the same version v0.2.2)
@robobun
import { writeFileSync } from "node:fs";
import { file } from "bun";
writeFileSync("./example.txt", "this is an example file");
console.log(await file("./test.txt").text());
@Electroid Here is the output of the code you provided.
error: ENOENT
path: "./test.txt"
syscall: "open"
Code was run using the latest build of Bun.
@robobun
import { writeFileSync } from "node:fs";
import { file } from "bun";
writeFileSync("./example.txt", "this is an example file");
console.log(await file("./example.txt").text());
@Electroid Here is the output of the code you provided.
this is an example file
Code was run using the latest build of Bun.
@Jarred-Sumner Looks like this is a more obscure error.
Confirming this still is happening on Codespaces instances, await file("./example.txt").text()
error: EBADF
path: "./example.txt"
syscall: "open"
@ConProgramming here you go!
1 |
2 | EBADF;
^
ReferenceError: Can't find variable: EBADF
at /tmp/bun-wvr908/index.tsx:1:7
Code
error: EBADF
path: "./example.txt"
syscall: "open"
Ran using the latest build of Bun, an all-in-one JavaScript runtime.
wonder what linux kernel version is being used in Codespaces and if that supports io_uring
on "5.4.119-1-tlinux4-0009-eks #1 SMP Wed Sep 28 23:05:45 CST 2022 x86_64 x86_64 x86_64 GNU/Linux" bun v0.5.6 triggers the same "EBADF" problem
on "5.4.119-1-tlinux4-0009-eks #1 SMP Wed Sep 28 23:05:45 CST 2022 x86_64 x86_64 x86_64 GNU/Linux" bun v0.5.6 triggers the same "EBADF" problem
我遇到了同样的问题 bun v0.5.7 linux mint 20.1
试试: // test.js console.log(await Bun.readableStreamToText(Bun.file("./test.txt").stream()))
using the above test code, the problem continues (on v0.6.14 ~ v1.0.7)
import { writeFileSync } from "node:fs";
import { file } from "bun";
writeFileSync("./example.txt", "this is an example file");
console.log(await file("./example.txt").text());
- this is running on a virtual machine, which failed with an error
EBADF
:
Linux vm-centos 5.4.119-1-tlinux4-0010.3 #1 SMP Thu Jan 5 17:31:23 CST 2023 x86_64 x86_64 x86_64 GNU/Linux;
- the same code runs without error but with ** no output ** in a docker container:
Linux docker-ctr-0 4.14.105-1-tlinux3-0020 #1 SMP Thu Apr 1 17:55:25 CST 2021 x86_64 x86_64 x86_64 GNU/Linux
any updates on this?
my google compute server throws this same error any time i try to read a file EBADF: Bad file descriptor
also it pegs the cpu at 100% usage
bun -v 1.0.0
Ubuntu 18.04.6 LTS uname -r 5.4.0-1096-gcp
seems like this error occurs only when using the bun
native function to do an IO operation on the file, replacing such function with node compatible fs
module functions works great
ex: replace Bun.write
to writeFileSync
I tested this example on Docker and I cannot reproduce. Is it safe to assume this is fixed now?
Still not working on bun 1.0.3 / Ubuntu 20.04
+1 Its happening on a remix app that uses tailwind too.
I have the same problem (
@LoGwi-N In the meantime, const text = await Bun.readableStreamToText(file.stream());
is working for me.
@LoGwi-N In the meantime,
const text = await Bun.readableStreamToText(file.stream());
is working for me.
Wonderfull, it's working.
Same on M1 Mac, inside the oven/bun
docker container running Vite 😔
@cbioley,
const text = await Bun.readableStreamToText(file.stream());
is working for me. thank you it's working. Ubuntu 20.04 const file = Bun.file(filePath); if (!file) { throw new Error(Failed to load ${filePath}
); } const stream = await file.stream(); const contents = await Bun.readableStreamToText(stream) console.log(contents);
Hi! Not 100% sure if its the right place but I see all Bad file descriptor issue are linked here.
I'm building a CLI with Bun and I read and write into package.json with it.
At running the tests on the pipeline, this Bad file descriptor issue shows up while in local everything works as expected.
After replace Bun.file and Bun.write with the node:fs replacements, local still works and now its working properly in the pipeline also.
Same ubuntu and linux version in local and the agent of the pipeline.
As I said not 100% if its related but it's clear that something it's not working properly with those functions.
Hope this info helps to fix it and thanks for the hard work! 😊
just want to note i have had cases where i've run into EBADF inside docker containers. it's hard to figure out exactly what is going on, but i suspect its from some file descriptor reuse, but it wouldn't explain why it's docker only. also, ive found that most fs functions can repro it if the situation is right, like readFileSync/writeFileSync/etc
does anyone get this issue outside of Docker? my case might be different if this issue happens outside of docker.
using the above test code, the problem continues (on v0.6.14 ~ v1.0.7)
import { writeFileSync } from "node:fs"; import { file } from "bun"; writeFileSync("./example.txt", "this is an example file"); console.log(await file("./example.txt").text());
- this is running on a virtual machine, which failed with an error
EBADF
:Linux vm-centos 5.4.119-1-tlinux4-0010.3 #1 SMP Thu Jan 5 17:31:23 CST 2023 x86_64 x86_64 x86_64 GNU/Linux;
* the same code runs without error but with ** no output ** in a docker container:
Linux docker-ctr-0 4.14.105-1-tlinux3-0020 #1 SMP Thu Apr 1 17:55:25 CST 2021 x86_64 x86_64 x86_64 GNU/Linux
![]()
@paperdave i have a vm and a docker container, but with slightly different situation.
Same here on digitalocean droplet
- OS
Linux 5.4.0-166-generic x86_64 x86_64
- Bun
1.0.7+b0393fba6200d8573f3433fb0af258a0e33ac157
Same result produced with different users and different file permissions
I'm still getting this in Bun v1.1.16 (Linux x64)
with await file('file.txt').text()
running in chokidar watch