| To: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH 02/12] xfsprogs: simplify leading '/' handling in generate_obfuscated_name() |
| From: | Alex Elder <aelder@xxxxxxx> |
| Date: | Mon, 10 Jan 2011 14:23:57 -0600 |
| Cc: | xfs@xxxxxxxxxxx |
| In-reply-to: | <20110110201335.GB27277@xxxxxxxxxxxxx> |
| References: | <1293741612.2294.354.camel@doink> <20110110201335.GB27277@xxxxxxxxxxxxx> |
| Reply-to: | aelder@xxxxxxx |
On Mon, 2011-01-10 at 15:13 -0500, Christoph Hellwig wrote:
> On Thu, Dec 30, 2010 at 02:40:12PM -0600, Alex Elder wrote:
> > In generate_obfuscated_name(), the incoming file name is allowed to
> > start with a '/' character, in which case it is copied over to the
> > new file name and ignored for the remainder of the hash calculation.
> > Simplify the affected code by processing the '/' right away, and
> > using a pointer thereafter for the start of the new file name.
>
> The actual change looks good to me, but why would we ever have a /
> in the filename, and if we do why would we treat it special?
>
This change was preserving the behavior that was there before.
I didn't ask that question... It may well be that there's no
need to even handle a filename starting with '/', but I didn't
follow it back to see.
-Alex
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH 01/12] xfsprogs: some things aren't all that special, Alex Elder |
|---|---|
| Next by Date: | Re: [PATCH] xfs_repair: multithread phase 2, Matthias Schniedermeyer |
| Previous by Thread: | Re: [PATCH 02/12] xfsprogs: simplify leading '/' handling in generate_obfuscated_name(), Christoph Hellwig |
| Next by Thread: | [PATCH] xfstests: add simple splice test, Dave Chinner |
| Indexes: | [Date] [Thread] [Top] [All Lists] |