| ▲ | ape4 an hour ago | ||||||||||||||||||||||
It somewhat odd that systems don't have a call to tell you how many files are in a folder. | |||||||||||||||||||||||
| ▲ | ygra an hour ago | parent | next [-] | ||||||||||||||||||||||
Either that call would have to do the same (i.e., walking the files and counting), or you'd need some additional metadata in the directory entry to store how many files there are, requiring additional storage accesses for adding and removing files. Adding to that that both FAT32 and NTFS are quite old and had to run on older hardware. Cycles and disk accesses are not free. On top of that, how often is it necessary to efficiently know the number of files in a directory while at the same time not caring about the files enough to list or display them? This algorithm is a special case where you could use the count of using a bit simpler code that ultimately would have the same file system API calls (since you cannot tell the FS to give you file #37 from that directory, so you'd have to use FindNextFile 37 times anyway, just like the sampling algorithm). | |||||||||||||||||||||||
| ▲ | eventualcomp an hour ago | parent | prev | next [-] | ||||||||||||||||||||||
I feel like there would either be too many locks or too much contention on something like /var/log or /tmp if that API was ever exposed to userspace. | |||||||||||||||||||||||
| ▲ | conorcleary an hour ago | parent | prev [-] | ||||||||||||||||||||||
just have it count how many times del cmd runs successfully /s | |||||||||||||||||||||||
| |||||||||||||||||||||||