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.wei...@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 <stanlukya...@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 < > stanlukya...@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 < > >> stanlukya...@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 < > >> dsetrak...@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 < > >>>> stanlukya...@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 > >>> > >>> > >> > >> > > > >
