svn commit: r214431 - head/bin/rm

[Alexander Best]

On Wed Oct 27 10, Juli Mallett wrote:
> On Wed, Oct 27, 2010 at 14:48, Alexander Best <arundel at freebsd.org> wrote:
> > On Wed Oct 27 10, Doug Barton wrote:
> >> What may be a better approach is to confirm the fs' that DO work, list
> >> them, and then add something to the effect of, "This feature is unlikely
> >> to work on other file systems."
> >
> > i don't think that's a good approach, because then the rm(1) has to be changed
> > everytime freebsd gets a new fs which works with the -P option. i think it's
> > better to list which fs semantics DON'T work. so if freebsd gets a new fs,
> > users simply have to know which semantics the new fs is based on and can decide
> > for themselves whether the -P switch will work or not.
> >
> > so far the -P option doesn't seem to work for:
> >
> > - COW fs and/or
> > - fs with a variable block size and/or
> > - fs which do journaling
> 
> I really don't want to ask the average user to know whether their
> filesystem is in-place block-rewriting or not.  That's just silly.  In
> this case Doug is right; I don't think FreeBSD gets new file systems
> as often as you think that it would be a big burden.  Having a general
> description of the types of filesystem it can work on might be useful,
> but a list seems more useful still.  Listing the types it can't work
> on is backwards because that requires a user to understand the
> dichotomy as well as knowing what kind of filesystem they don't have /
> do have.  And for them to never get it backwards.  At least mount(8)
> will tell you what filesystem you are using; there's no tool to tell
> you the properties of your filesystem, and good luck easily-mining an
> answer to the question of whether your filesystem fits into that
> category from a manpage without introducing substantial confusion.
> 
> Maybe there should be substantial confusion around this feature,
> though, since that's what it seems to be there for.

how about fusefs? i think there's an ongoing disussion about importing it into
HEAD on arch@ or fs at . won't this bring in support for a number of new
filesystems which then all have to be documented in the rm(1) manual?

but if in fact all working fs should get mentioned...what are they?

- UFS1/2
- ext2fs
- FAT12/16/32

...any more? what about memory backed fs like tmpfs?

cheers.
alex

> 
> Juli.

-- 
a13x