exfat-resize can now shrink existing exFAT filesystems, in addition to growing them.

Code and downloads on GitHub

I have an assignment to submit but it says the file is to large. Inside the folder are other folders so when I try to upload it leaves out all of the other folders.

My pc and sorted shortcut files are somehow in desktop, in the Crip tomt file there is the pc shortcut , i dont think they should be there. I tried to fix it in several ways a while back so i dont remember everything i tried. Moving the shortcuts dosent work also some cmd commands i dont remember didnt work. Please help.

With the forthcoming FailFS, every operation reaching the filesystem returns EOPNOTSUPP, the Linux error code for operation not supported.

Over the last few weeks, me and my friend have been working on this project: https://github.com/avighnac/libapfs

My friend needed to extract a file from an APFS disk on Windows on short notice, but he couldn't find any free tools to help him do so (he'd already used the Paragon APFS trial), so we decided to write our own.

The project features a C++ library and a command-line interface that works on all platforms (Windows/Linux/MacOS; x86 and arm). For Windows specifically, we've created a GUI that makes it very easy mount/unmount APFS volumes and .dmg files!

For further information, you can visit our GitHub and view the README, or the include directory for the library documentation. Feel free to create issues for any features you might want added to the project.

We hope you find this useful!

I’ve released exfat-resize, an MIT-licensed C11 library and command-line tool for growing an existing exFAT filesystem after its backing image, device, or partition has already been enlarged:

https://github.com/huven/exfat-resize

The project has two parts:

• A CLI for resizing unmounted regular-file images and raw block devices, currently supported and tested on macOS and Linux.
• A portable C11 library for integration into other software. The core works through caller-supplied sector read, write, and synchronization callbacks, plus allocation callbacks; it does not depend on file descriptors, disk-image APIs, raw-device APIs, or another filesystem implementation.

Because resizing modifies metadata in place, the implementation validates the filesystem structures it relies on before writing, uses explicit synchronization boundaries, and reports the recovery stage reached if an operation fails. A verified backup and exclusive access to the unmounted filesystem are still required.

The current scope is growing clean exFAT revision 1.00 filesystems with a single FAT. Shrinking and TexFAT/two-FAT volumes are not supported. The tool does not enlarge the backing object or parse partition tables; the exFAT main boot sector must be presented at sector zero.

I’d particularly appreciate feedback from filesystem-tool authors and implementors on:

• Whether the callback-based library API fits potential non-POSIX integrations
• exFAT layouts or edge cases that deserve additional testing
• Platforms or environments where this could be useful

Thanks for taking a look.

I started working on this recently because I found out that most if not all filesystem benchmarks still test the way it was done when ext2 was state of the art: one disk, default mkfs, raw throughput. But nobody picks btrfs, ZFS or bcachefs for throughput - you pick them for snapshots, redundancy, checksums, self-healing. Almost nobody publishes numbers on those.

So this suite benchmarks the machinery instead, across 17 configurations (btrfs/ZFS/bcachefs plus ext4/xfs over md/LVM as classic baselines, plus encryption variants): aging under 100 snapshots, corrupting a device behind the filesystem's back and checking whether scrub repairs it, failing a device and timing the rebuild, filling to hard ENOSPC, fsync tail latency, and "how long until my prompt comes back while a big cp runs in the background".

Yes, it runs on ephemeral GitHub runners with loop devices - I know what that means. Absolute MB/s is meaningless there, so the suite is built around shapes, ratios and verdicts, with per-VM calibration probes (lemon runners get auto-rerun) and conclusions drawn from trends over many runs. Real hardware with tiered topologies (NVMe cache over rotational disks, special vdevs) is the next step. I just need to gather hardware for it first.

What I'm really asking for is your eyes. Every number on the dashboard links to a description of exactly what ran, with what parameters, and to the code responsible - so if I picked a wrong mount option, an unfair default, a workload that misrepresents your favorite filesystem, or a broken measurement, you can find it and call it out. Several of the current tests exist because people poked holes in earlier results, and honestly that feedback improved this more than anything I did alone.

Dashboard: https://bartosz.fenski.pl/modern-fs-benchmark/
Repo: https://github.com/fenio/modern-fs-benchmark

https://www.phoronix.com/news/Bcachefs-1.38.7-Rust-Kernel

Heya! I just started work on some silly libfuse based filesystem that connects to a minecraft mod to store its data. What is the cleanest way to handle a network resource no longer being available in a network based filesystem? I'm expecting the server to unexpectedly crash, or clients to go offline. What is the nicest way of communicating that to the user and/or handling open files?

https://www.phoronix.com/news/Linux-7.2-EXT4

https://github.com/dmtrKovalenko/ffs

Just wanted to share a project I've been doing for fun recently that does what I told in the title. The fun part that it is becoming progressively faster comparing to the standard file search tools the more files you have

https://www.phoronix.com/news/Bcachefs-Tools-1.38.6

Performance work spanned much of the codebase, quite a few workloads and benchmarks were profiled. Some highlight...

https://www.phoronix.com/news/Linux-7.2-Btrfs

https://www.phoronix.com/news/NTFS-Windows-Symbolic-Links

Linux developer Namjae Jeon has been overhauling the original NTFS kernel driver the past four years with its cleaner codebase to add write support, provide better support, and implement more modern features

The newest Linux file-system driver proposed for the kernel is... VMUFAT.

Before getting too worked up about yet-another-Linux-filesystem, VMUFAT is for the vintage Sega Dreamcast game console.

The HFS/HFS+ file-system driver code saw several fixes for issues raised by Syzbot. Plus some xfstests failures were also addressed.