[HELP] FAT: How should unlink defer cluster-chain deletion for open files?

[arnavsharma990]

Description

Hi NuttX community,

I'm looking into the TODO in fs/fat/fs_fat32.c regarding rmdir()/unlink() behavior when a file or directory is still open:

"Need to defer deleting cluster chain if the file is open."

I've been investigating the current FAT implementation and prototyped a small fix using a pending-delete state on struct fat_file_s and the existing fs_head open-file list.

However, I ran into an identity/lifetime question.

Using ff_startcluster to determine whether an open handle belongs to the unlinked file does not seem safe because:

• an empty file has ff_startcluster == 0 and can acquire a cluster later when written;
• cluster numbers can be reused;
• ff_dirsector / ff_dirindex represent the directory entry location, but directory entries can be moved by rename and reused after unlink;
• fat_dup() currently creates another fat_file_s rather than sharing a canonical underlying file object.

So I'm wondering what the intended design is here.

Would the preferred approach be to introduce some small FAT-local per-file identity/lifetime state (for example, a canonical fat_file_s with a reference count and pending-delete state), or is there an existing FAT/VFS mechanism that should be used for associating open handles with the underlying file across unlink/rename?

I would appreciate any guidance on the intended approach before I open a PR.

Thanks!

Verification

• I have verified before submitting the report.

[arnavsharma990]

I’ve also considered a possible direction of keeping the deferred-delete state at the open-file-object level rather than using ff_startcluster or directory-entry location as the identity.

For example, a shared FAT-local open-file object with a reference count and pending-delete state could make the lifetime explicit, with fat_dup() sharing that object.

I’m mainly looking for confirmation from the maintainers on whether this fits the existing NuttX/FAT design, or if there is a preferred approach I’ve overlooked.