You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 20, 2022. It is now read-only.
The current code marks a dentry as DENTRY_NEGATIVE when removing or renaming it. As a result, when we create a new file with the same name, the dentry is reused, even though it's no longer in a "fresh" state (various fields might have been changed).
This has already caused a bug related to the fs field overriden for special files (see #2499, #2505).
Solution
On file delete, mark a dentry as invalid. It will be destroyed (by dentry_gc()) when all external references to it are dropped.
On lookup, we should consider only valid dentries. This way, we can require the dentry to have a unique name as long as it's valid, but there can be many "ephemeral" invalid dentries with the same name.
This would also allow an open handle to a deleted file to work reasonably well.
I started coding this in #2505, but found out it would be good to refactor tmpfs/strfs first, as it does its own reference counting for dentry data that interferes with the refactoring.
Alternatives
Instead of creating new dentries, we could "wipe" dentries on reuse, but that sounds hacky and does not handle open handles to a dentry.
Instead of relaxing the "unique name" requirement, we could rename old dentries on delete? I'm not sure if that's any better, but it depends on what else we'll be using the name for.
The text was updated successfully, but these errors were encountered:
Problem
The current code marks a dentry as
DENTRY_NEGATIVE
when removing or renaming it. As a result, when we create a new file with the same name, the dentry is reused, even though it's no longer in a "fresh" state (various fields might have been changed).This has already caused a bug related to the
fs
field overriden for special files (see #2499, #2505).Solution
dentry_gc()
) when all external references to it are dropped.This would also allow an open handle to a deleted file to work reasonably well.
I started coding this in #2505, but found out it would be good to refactor tmpfs/strfs first, as it does its own reference counting for dentry data that interferes with the refactoring.
Alternatives
Instead of creating new dentries, we could "wipe" dentries on reuse, but that sounds hacky and does not handle open handles to a dentry.
Instead of relaxing the "unique name" requirement, we could rename old dentries on delete? I'm not sure if that's any better, but it depends on what else we'll be using the name for.
The text was updated successfully, but these errors were encountered: