ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Handling slashes in cache names
Date Wed, 27 Dec 2017 11:36:58 GMT
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