In other words, If we keep the DirEntry, the InnerReader inner Arc wouldn't be dropped, that's: directory fd wouldn't be released even through we drop ReadDir through max_open control ! So, we could encounter Too many open files error when using collect on the iteration when walking a big enough directory !
However, luckily, we use our impl DirEntry instead of std version since it doesnt hold the fd reference. We just need to document it as additional doc comment before our DirEntry!
Fix staled comments on
DirList,DirEntry,IntoIterIt's said that these structure relies on
std::fs::DirEntrywhich is outdated since we use ourcrate::dent::DirEntrySupply additional comment for difference between std
DirEntryand ourDirEntryI've no idea if we've noticed that std DirEntry hold a reference of opened dir as the documented mentioned.
In a detail, on Unix implementaions:
ReadDirholds an Arc ofInnerReadDir, and it shares it withDirEntry.readdirReadDirImpl Iterator for ReadDirDirEntryThe
InnderReadDirholds theDirwhich is an wrapper of platform native opaqueDIR.DIRWhen the
InnerReadDiris dropped, it calls nativeclosedirwould close underlying fd associated.impl Drop for DirclosedirIn other words, If we keep the
DirEntry, theInnerReaderinnerArcwouldn't be dropped, that's: directory fd wouldn't be released even through we dropReadDirthroughmax_opencontrol ! So, we could encounterToo many open fileserror when usingcollecton the iteration when walking a big enough directory !However, luckily, we use our impl
DirEntryinstead of std version since it doesnt hold the fd reference. We just need to document it as additional doc comment before ourDirEntry!