From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] Btrfs: don't allow a subvol to be deleted if it is the default subovl
Date: Tue, 13 Aug 2013 04:54:32 +0000 (UTC) [thread overview]
Message-ID: <pan$445b2$64e1e159$c2f6f85b$84d1e879@cox.net> (raw)
In-Reply-To: 1376336375-20631-1-git-send-email-jbacik@fusionio.com
Josef Bacik posted on Mon, 12 Aug 2013 15:39:35 -0400 as excerpted:
> Fix this by adding a check to see if our default subvol points to the
> subvol we are trying to delete, and if it does not allowing it to
> happen.
Umm... not to be a grammar policeman, but...
That last sub-sentence REALLY (!!) needs another comma:
... and if it does, not allowing it to happen.
or
... and if it does not, allowing it to happen.
The way it is now ends up triggering for the reader a serious logical
train wreck, as "does not" and "not allowing" both "want" to be parsed
together, but "does not allowing" derails the whole thing and the reader
must start over, taking it more slowly this time, trying to figure out
where the parsing derailed the first time through and what was actually
intended!
(FWIW, being a languagelog.net feed subscriber and regular reader, I see
instances of this sort of logical train wreck, as it's frequently
analogized, feature there regularly. Linguists know it as an interesting
quirk of the English language both created and spotted regularly by
experts and novices alike, sometimes with rather amusing consequences!)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2013-08-13 4:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-12 19:39 [PATCH] Btrfs: don't allow a subvol to be deleted if it is the default subovl Josef Bacik
2013-08-13 4:54 ` Duncan [this message]
2013-08-13 14:14 ` Josef Bacik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='pan$445b2$64e1e159$c2f6f85b$84d1e879@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).