Saving to exFAT partition (Linux) causes "Bad address (os error 14). Please try again."

[maxwowpow]

Check for existing issues

• Completed

Describe the bug / provide steps to reproduce it

Linux/Fedora: have an exFAT mounted partition.
Try save a file there with zed (new/edit - doesn't matter).

Expected: file saved.

Happens: file saved, but additionally an error "Bad address (os error 14). Please try again." shown.

Notes:

• zed saves on EXT4/SMB ok (w/o error).
• inotify works (see commend below).
• vscodium and other apps save OK on exfat.
• initially suspected veracrypt fuse mount is not the culprit.

Ideas: which api called to save a file? trying to write any ACL on exfat?

Environment

6.11.10-300.fc41.x86_64

It happens on MacOS 15.1 APFS too (not exFAT) but I'll validate later, that it's "os error 14" code too.

If applicable, add mockups / screenshots to help explain present your vision of the feature

No response

If applicable, attach your Zed.log file to this issue.

Zed.log

2024-11-11T23:42:08.312690848+01:00 [INFO] extensions updated. loading 0, reloading 0, unloading 1
   6 2024-11-11T23:42:08.314015983+01:00 [INFO] Initializing default prettier with plugins {}
   5 2024-11-11T23:42:08.314415675+01:00 [INFO] Initializing default prettier with plugins {}
   4 2024-11-11T23:42:24.362131793+01:00 [INFO] Creating a descriptor pool for at most 16 sets
   3 2024-11-11T23:42:24.362350595+01:00 [INFO] Creating a descriptor pool for at most 256 sets
   2 2024-11-11T23:42:24.3748059+01:00 [INFO] Creating a descriptor pool for at most 16 sets
   1 2024-11-11T23:42:24.375173732+01:00 [INFO] Creating a descriptor pool for at most 256 sets
949  2024-11-11T23:44:03.451448898+01:00 [ERROR] Bad address (os error 14)
   1 2024-11-11T23:44:03.551014792+01:00 [ERROR] ignoring event "/media/veracrypt1/x/!incoming.md" outside of root path "/media/veracrypt1/y"
   2 2024-11-11T23:44:42.152411934+01:00 [ERROR] Bad address (os error 14)
   3 2024-11-11T23:44:42.252620767+01:00 [ERROR] ignoring event "/media/veracrypt1/x/!incoming.md" outside of root path "/media/veracrypt1/y"
   4 2024-11-11T23:44:51.923134418+01:00 [ERROR] Bad address (os error 14)
   5 2024-11-11T23:44:52.023191135+01:00 [ERROR] ignoring event "/media/veracrypt1/x/!incoming.md" outside of root path "/media/veracrypt1/y"
   6 2024-11-11T23:44:55.614439268+01:00 [ERROR] Bad address (os error 14)
   7 2024-11-11T23:44:55.714681293+01:00 [ERROR] ignoring event "/media/veracrypt1/x/!incoming.md" outside of root path "/media/veracrypt1/y"
   8 2024-11-11T23:45:01.695419013+01:00 [ERROR] window not found
   9 2024-11-11T23:45:01.69547618+01:00 [ERROR] window not found
  10 2024-11-11T23:45:01.699631311+01:00 [ERROR] oneshot canceled

[notpeter]

To be clear, this is not a regular exFAT FS with the mount handled by the kernel, right? It's a FUSE filesystem implemented ontop of exFAT I think I wonder if the issue is because most FUSE filesystems do not support inotify.

Perhaps related:

• Support for manually refreshing projects when inotify/fsevents unavailable (e.g. on nfs file shares) #20044

[maxwowpow]

• the problem exists when exfat is handled by the kernel too. tested with a simple usb dongle formatted with exfat. no fuse/veracrypt involved.
• /dev/sdd1 exfat rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro

inotifywait -m /run/media/max/MX16/
Setting up watches.
Watches established.
/run/media/max/MX16/ CREATE 1.md (2)
/run/media/max/MX16/ OPEN 1.md (2)
/run/media/max/MX16/ CLOSE_WRITE,CLOSE 1.md (2)

PS:

• smb:// mounts work flawlessly,
• when I open an smb file the path is /run/user/1000/gvfs/xxx
• GVfs uses FUSE afaik fuse.gvfsd-fuse

PS2 extra verified for/with veracrypt fuse.veracrypt + kernel mount of /dev/mapper/veracrypt1 as exfat:

inotifywait -m /media/veracrypt1
Setting up watches.
Watches established.
/media/veracrypt1/ CREATE 1.md
/media/veracrypt1/ OPEN 1.md
/media/veracrypt1/ CLOSE_WRITE,CLOSE 1.md
/media/veracrypt1/ OPEN 1.md
/media/veracrypt1/ CLOSE_NOWRITE,CLOSE 1.md
/media/veracrypt1/ OPEN 1.md
/media/veracrypt1/ MODIFY 1.md
/media/veracrypt1/ MODIFY 1.md

[notpeter]

Exfat kernel module appears to puke if you try and write an empty file.
I am able to reproduce without a exfat drive and without Zed:

mkdir /tmp/exfat
cd $_
fallocate -l 512M exfat.img
mkfs.exfat exfat.img

sudo mkdir -p /fatimagedir/
sudo mount -o umask=0022,gid=$(id -g),uid=$(id -u) /tmp/exfat/exfat.img /fatimagedir/

cd /fatimagedir
python3 -c 'open("foo", "wb", buffering=0).write(b"")'

Output

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 14] Bad address

Zed might be able to work around this, but this is definitely an upstream bug and not anything Zed-specific (even if VSCode and other tools work with Exfat).

Links:

• https://bbs.archlinux.org/viewtopic.php?id=294837

[maxwowpow]

great find, sorry I didn't go deeper to eliminate the zed's fault.

still it's happening in zed with every save, not only of an empty file.

other editors if spitting an error while creating a new file, manage to save a non empty file w/o extra errors.

[notpeter]

I haven't dug further into our fs implementation to confirm, but my guess is that if you peeled back the onion you'd find that we first write 0 bytes to create the file (if not existent) and then write write the file in chunks. Perhaps this could be modified to avoid the len=0 writes.

Thank you for filing the upstream issue.

[maxwowpow]

zed/crates/fs/src/fs.rs

Line 536 in ccf2a60

tmp_file.persist(path)?;

seems like a temp file being created every time to do an atomic replace with a new version of the file? Would explain the error on every save.

how about specifying a custom temp/cache dir for those operations?
that way if a user has a fs with expected features (ext4/apfs/ntfs... and uses exfat for external storage) it should work in theory.

the alternative to write a full file w/o creating an empty file (or rather a temp file) could lead to data corruption during the write?

personally i got an impression it's not really a exfat bug but rather not existing feature. Touch'ing a file on exfat doesn't intrinsically throw any errors. 👀

[notpeter]

how about specifying a custom temp/cache dir for those operations?
that way if a user has a fs with expected features (ext4/apfs/ntfs... and uses exfat for external storage) it should work in theory.

I think this would conceivably work. It might also be helpful for other non-compliant filesystems (e.g. random FUSE drivers, etc).

personally i got an impression it's not really a exfat bug but rather not existing feature.

No. It's definitely a bug. The exFAT implementation of write is not POSIX compliant because cannot handle calls where the number of bytes nbyte is 0. From POSIX spec for write():

ssize_t write(int fildes, const void *buf, size_t nbyte);

Before any action described below is taken, and if nbyte is zero and the file is a regular file, the write() function may detect and return errors as described below. [...]

[maxwowpow]

The exfat was never posix compliant, because of many things included but not limited to permissions and symlinks.
The implementation could have been inspired by some posix compliance, however i found no mention of it in the code.
In any case it sounds like an improvement, bug or not.

zed/crates/fs/src/fs.rs

Line 517 in ccf2a60

let mut tmp_file = if cfg!(any(target_os = "linux", target_os = "freebsd")) {

#8437

If a temporary file is created on a different filesystem or mount point than the final destination file, operations like persist or rename can fail due to the operating system’s inability to move files across different devices or mount points atomically. By placing the temporary file in the same directory as the final target file, the persist or rename operation stays within the same filesystem, preventing cross-device link (EXDEV) errors.

[maxwowpow]

Further tests in a simple app https://github.com/maxwowpow/test_rust_fs_atomic
did not yield any warnings/errors.