[aklug] Re: Linux/BSD: Why do directories need to be empty?

actually as far as I know this has been the default of RM for as long as =
I have been a unix admin. That's what the -f is for=85 forced. It's =
supposed to override this condition and delete it anyway.

Jim MacDonald
jim@macdonald.org

On May 15, 2011, at 4:32 PM, Shane Spencer wrote:

> On Sat, May 14, 2011 at 3:51 PM, Christopher Howard
> <christopher.howard@frigidcode.com> wrote:
>> Why is it that on Linux and BSDs that the system requires directories =
to
>> be empty before they are deleted? A directory is fundamentally just a
>> file, right? Why shouldn't I be able to just unlink it and let the =
child
>> files disappear by virtue of having no more references to them in the
>> file system tree? Instead of that simple approach, I have to =
recursively
>> unlink every child file and rmdir every subdirectory (or, of course, =
let
>> "rm -rf" do it for me.) Seems lame.
>>=20
>> This was kind of problematic for me the other day because I had a =
script
>> that was supposed to "rm -rf" a certain backup directory, but it
>> actually wasn't doing it completely because there were some
>> subdirectories that didn't have their write permission bits set.
>>=20
>=20
> I'm not sure if you're familiar with how databases are indexed but
> most filesystems are indexed to a similar degree. In order to list
> files in a directory the operating system needs to know where to look
> first and then it can iterate through files that match that path.
> Files have parent's for the most part and those parents are indexed in
> a way that allows children to be reallocated to different parents
> quickly. Directories are in many cases simply nodes in the filesystem
> that don't contain data blocks.
>=20
> Removing small files has a comparable speed to removing directory
> entries.. large files take more time as individual blocks are
> reallocated for use. Removing a directory would abandon child data
> and blocks would have to be reallocated for use. All of this could be
> done in the background and the file nodes could be temporarily
> re-parented to a different directory within the same filesystem. I
> believe there are some tools that do exactly this out there.
>=20
> There are quite a few reasons not to remove files in the background
> that would complicate a majority of the common tools we use. The
> biggest one I can think of is that removing a file is something you
> mean to do and you do so knowing you are reclaiming space and a little
> acknowledgement by way of an error code or a clean exit goes a long
> way. If files go missing and that space isn't immediately reclaimed
> then your process may be expecting something it isn't getting. Why
> bother making the deletion asynchronous (rhetorical)?
>=20
> In the end.. reallocating + deleting through a forked process
> (~/Trash, C:\Recycle Bin) works pretty durn well.
>=20
> If you want speed and acknowledement, check out the reallocation
> (deletion) rates of other filesystems than what you are using.
>=20
> - Shane
>=20
>> --
>> frigidcode.com
>> theologia.indicium.us
>> ---------
>> To unsubscribe, send email to <aklug-request@aklug.org>
>> with 'unsubscribe' in the message body.
>>=20
>>=20
> ---------
> To unsubscribe, send email to <aklug-request@aklug.org>
> with 'unsubscribe' in the message body.
>=20

---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Thu May 26 07:35:35 2011