ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Sapego <isap...@apache.org>
Subject Re: Handling slashes in cache names
Date Wed, 27 Dec 2017 13:18:42 GMT
I personally like a Pavel's suggestion - base64 encoding seems like
a good solution, while string hashes will arise a collision issue.

Best Regards,
Igor

On Wed, Dec 27, 2017 at 3:29 PM, Petr Ivanov <mr.weider@gmail.com> wrote:

> Special characters banning seems to be exclusive way and cannot be
> controlled in future if new symbols arise.
> Maybe better solution will be choosing the array of permitted symbols for
> caches names (i.e. [a-zA-Z0-9_-])?
>
>
> Also +1 for using abstract hash string for directories names.
>
>
> > On 27 Dec 2017, at 15:14, Stanislav Lukyanov <stanlukyanov@gmail.com>
> wrote:
> >
> > We can – by mapping a cache name to some (safe) string to be used as a
> directory name, say via Base64 as Pavel has suggested.
> >
> > However, I think that banning certain characters might be reasonable.
> > Some characters might be considered reserved (e.g. slashes, colon,
> asterisk, etc) to be used later, in case some future feature requires cache
> names to have an actual meaning.
> > Some characters might be banned just as a precaution (e.g. control
> characters or whitespaces) because they might cause problems with logging
> or elsewhere (you might have a bad time processing a cache name with \0 in
> it :) ).
> >
> > The question is whether or not these considerations worth adding code
> and/or changing existing behavior.
> >
> > BTW Java folks had similar discussion on Java module names resulting in
> http://mail.openjdk.java.net/pipermail/jpms-spec-experts/
> 2016-December/000515.html.
> >
> > Thanks,
> > Stan
> >
> > From: Vladimir Ozerov
> > Sent: 27 декабря 2017 г. 14:37
> > To: dev@ignite.apache.org
> > Subject: Re: Handling slashes in cache names
> >
> > Cache name appears to me purely logical entity. Can we simply store cache
> > ID in file system paths without adding any restrictions to cache names?
> >
> > On Wed, Dec 27, 2017 at 2:26 PM, Stanislav Lukyanov <
> stanlukyanov@gmail.com>
> > wrote:
> >
> >> Well, that’s my question too :)
> >> Do we have any compatibility guidelines or other documents on what can
> or
> >> cannot be in a minor/major release?
> >>
> >> Also, it might be helpful to add an environment variable (like
> >> IGNITE_DISABLE_CACHE_NAME_RESTRICTIONS) to restore the old behavior,
> just
> >> in case.
> >>
> >> Thanks,
> >> Stan
> >>
> >> From: Dmitriy Setrakyan
> >> Sent: 26 декабря 2017 г. 17:02
> >> To: dev@ignite.apache.org
> >> Subject: Re: Handling slashes in cache names
> >>
> >> Looks good to me. Is this going to be an exception on startup? If yes,
> is
> >> it safe to release it, or should we wait till 3.0?
> >>
> >> On Tue, Dec 26, 2017 at 2:08 AM, Stanislav Lukyanov <
> >> stanlukyanov@gmail.com>
> >> wrote:
> >>
> >>> Thanks for the feedback.
> >>>
> >>> It seems that another thing to handle is case-insensitive FS –
> “mycache”
> >>> and “MyCache” is the same on Windows, so it might be reasonable to
> >> disallow
> >>> having two caches with names that are equal ignoring case.
> >>> And one more thing is control characters – forbidding at least range of
> >>> ASCII 0x00-0x20 seems reasonable.
> >>>
> >>> To summarize, a possible set of restrictions would be
> >>> - Whitespace characters (via Character.isWhitespaceCharacter)
> >>> - Control characters (via Character.isISOCharacter)
> >>> - Slashes
> >>> - Characters reserved in Windows (<>:"/\|?*)
> >>> - Length (say, up to 255)
> >>> - Distinct names of caches when ignoring case
> >>> It seems reasonable to enforce that even regardless of persistence
> >>> directories naming (AFAIU that’s what Dmitry meant by forbidding things
> >>> altogether), so that’s what I’m going to do.
> >>> Any concerns?
> >>> Specifically, would it be OK from backward compatibility point of view
> to
> >>> forbid all these characters now for all caches?
> >>>
> >>> Thanks,
> >>> Stan
> >>>
> >>>
> >>> From: Alexey Kuznetsov
> >>> Sent: 26 декабря 2017 г. 7:51
> >>> To: dev@ignite.apache.org
> >>> Subject: Re: Handling slashes in cache names
> >>>
> >>> It also make sense to limit cache name length to reasonable length.
> >>> Because some File systems could have limitations on path length.
> >>> See: https://en.wikipedia.org/wiki/Filename#Length_restrictions
> >>>
> >>> On Tue, Dec 26, 2017 at 1:41 AM, Dmitriy Setrakyan <
> >> dsetrakyan@apache.org>
> >>> wrote:
> >>>
> >>>> My preference would be to prohibit forward and backward slashes in
> >> cache
> >>>> names altogether, as they may create a false feeling of some directory
> >>>> structure, which does not exist. We should also prohibit spaces as
> >> well.
> >>>>
> >>>> D.
> >>>>
> >>>> On Mon, Dec 25, 2017 at 7:09 AM, Stanislav Lukyanov <
> >>>> stanlukyanov@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> I’m looking into https://issues.apache.org/jira/browse/IGNITE-7264,
> >>> and
> >>>> I
> >>>>> need some guidance on what’s the best way to approach it.
> >>>>>
> >>>>> The problem is that cache names are not restricted, but if
> >> persistence
> >>> is
> >>>>> enabled the cache needs to have a corresponding directory on the
file
> >>>>> system (“cache-…”) which can’t be created if the cache name
contains
> >>>>> certain characters (or a reserved system name).
> >>>>>
> >>>>> A straightforward approach would be to check if a cache name is
> >> allowed
> >>>> on
> >>>>> the local system (e.g. via `Paths.get(name)`) and fail to create
> >> cache
> >>> if
> >>>>> it isn’t, but I’m a bit concerned with the consistency of the
> >> behavior
> >>>> (the
> >>>>> same cache name be allowed on one system and not on another).
> >>>>> I think a better way would be to replace special characters (say,
all
> >>>>> non-alphanumeric characters) with underscores in file names (not
> >>> changing
> >>>>> the cache configuration). Would this be OK? Are there any risks
I’m
> >> not
> >>>>> considering?
> >>>>>
> >>>>> WDYT?
> >>>>>
> >>>>> Thanks,
> >>>>> Stan
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Alexey Kuznetsov
> >>>
> >>>
> >>
> >>
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message