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:27:01 GMT
Also, considering case-insensitivity issue, we need to choose
some encoding that only uses upper or lower case letters in
encoding result.

By the way, such encoding will resolve cache name clashes
due to case-insensitivity issue.

Best Regards,
Igor

On Wed, Dec 27, 2017 at 4:18 PM, Igor Sapego <isapego@apache.org> wrote:

> 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/201
>> 6-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