svn commit: r214431 - head/bin/rm
arundel at freebsd.org
Wed Oct 27 22:38:56 UTC 2010
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?
...any more? what about memory backed fs like tmpfs?
More information about the svn-src-head