Failed to remove empty directory

[l1ndb3ck]

Unable to remove some empty directories.

No entries found using code:
DIR *dir = opendir("/path/to/directory");
struct dirent *entry;
while ((entry = readdir(dir)) != NULL)
printf("Found: %s\n", entry->d_name);
closedir(dir);

And using:
unlink("/path/to/directory"),
return RED_ENOTEMPTY

When CoreUnlink() is called, ino.pInodeBuf->ullSize not is zero size.

How to fix this?

[danielrlewis]

Hi @l1ndb3ck, can you share which version of Reliance Edge you are using? The faulty behavior you are describing sounds very similar to a bug which was fixed in Reliance Edge v2.6. That bug was fixed in commit 75b1efb on the master branch (also backported to the v2_5_1_Release branch in commit d092ba3). Copied below is the associated commit message from the internal repository, which describes the problem in detail:

core: fix dirent deletion bug

Fix a bug in RedDirEntryDelete() which affected configurations where
the values of REDCONF_NAME_MAX and REDCONF_BLOCK_SIZE resulted in
unused space at the end of directory blocks.

Previously, when RedDirEntryDelete() removed the last entry in a
directory block, it would truncate the directory inode to a block-size
aligned value, such that the entirety of the previous directory block
(including any unusable space) would be included in the inode size.
However, that causes problems if entries from the previous block are
subsequently deleted.  RedDirEntryDelete(), near the start, has the
following check to determine whether truncation is needed:

    else if((DirEntryIndexToOffset(ulDeleteIdx) + DIRENT_SIZE) == pPInode->pInodeBuf->ullSize)

If ulDeleteIdx is the last dirent in a directory block, that check only
works if ullSize doesn't include unused space.

To illustrate the problem, consider the case where REDCONF_NAME_MAX
is 256 and REDCONF_BLOCK_SIZE is 4096.  Each dirent is 260 bytes.
A 4096-byte directory block can fit 15 dirents; because we do not split
dirents across block boundaries, there will be 196 unused bytes at the
end of each directory block.  Suppose a directory has 16 dirents and
no sparse dirent slots: that directory will have two blocks, with the
second block containing only one entry.  If the dirent in the second
block is deleted, previously we set the inode size to 4096.  If then
the last dirent in the remaining block was deleted, the "else if" check
would compute (14*260)+260=3900 for the left-hand side, which != 4096.
As a result, we would fail to truncate the inode when deleting the last
entry.  If subsequently the remaining dirents were deleted, the inode
size would still be 4096; the directory would be empty, but its nonzero
size would prevent it from being deleted.

With this fix, when the dirent in the second block is deleted, the
inode size will instead be set to 3900, with the result that subsequent
deletions will continue to reduce the inode size.

This problem is also mentioned in the release notes for v2.6:

Fix a bug where, after deleting all the files in a directory, the directory could still have a nonzero size, preventing it from being deleted. This bug could only manifest when the directory entry size was not an integral divisor of the block size. In other words, when the following was true: REDCONF_BLOCK_SIZE % (REDCONF_NAME_MAX + 4) != 0

If you are using a version of Reliance Edge which antedates that bug fix, I would recommend upgrading (or backporting the referenced commit) to prevent directories from getting into this broken state in the future.

If you are using a version of Reliance Edge which includes that bug fix, then something else is going on. In that case, please attach your redconf.h and redconf.c, and share whatever you can about how your application is modifying directories.

[l1ndb3ck]

Hi @danielrlewis
We are using version 2.2, and our developer has included some code (mostly debug) inside RE, so we are having some difficulty updating now and checking this, but I hope it will be soon.
Thanks for the quick response and if the problem persists, we will request support again.
Best regards.

[l1ndb3ck]

Hi @danielrlewis
We update to version 2.6 and the problem continues.
code else if((DirEntryIndexToOffset(ulDeleteIdx) + DIRENT_SIZE) == pPInode->pInodeBuf->ullSize) is inside function RedDirEntryDelete(), but this is called only after code if(ino.fDirectory && (ino.pInodeBuf->ullSize > 0U)) that return ret = -RED_ENOTEMPTY; before fix, in function CoreUnlink()
Regards.

[danielrlewis]

@l1ndb3ck:

Upgrading to Reliance Edge v2.6 will only prevent the directory size bug from occurring in the future. It will not retroactively fix broken directory sizes which already exist on the volume, which is the situation you are describing. ino.pInodeBuf->ullSize should be zero, but it's not because the v2.2 version of RedDirEntryDelete() did not update the size correctly. The v2.6 version of RedDirEntryDelete() has been fixed so that it won't introduce any further instances of this problem, but that doesn't repair any existing directories whose sizes were already broken by the old version of the function.

If the volume is reformatted with v2.6, so that all the directories are recreated, then the problem won't recur. This is the only solution which is available using the code we have formally tested and released.

If reformatting your volume(s) isn't possible, it would be possible to repair the broken directory sizes, either by scanning the volume for broken directories and repairing them all at once, or by fixing them as they are encountered during normal operations. The latter approach might look something like this patch: i.e., immediately prior to a directory deletion attempt, check if the directory size is broken, and (if it is) repair it. I will caution that the linked patch was hastily created, barely tested, and hasn't been reviewed by the broader team. If you would prefer a solution which has been through quality assurance, please contact sales@tuxera.com.