-
Notifications
You must be signed in to change notification settings - Fork 123
Key Name Ordering broken #38
Comments
Confirmed, happens with other plug-ins too. |
Great, then it is not my broken system :). Maybe we could take this as an opportunity to review the KeySet sorting. |
This issue may have nothing to with mounting, you can also reproduce it with:
Or for C code see 8b655c8 |
The problem is simple that this is the sort order of strcmp as used in keyCmpInternal(). |
One other way to fix the issue would be to duplicate the names for every key, replace / by 0 and use memcmp. This would also allow more efficient iteration over the key name, but more memory would be needed obviously. |
so using memcmp and having a duplicated name with 0 instead of / seems the only sane variant (about 30% of CPU time is spent in keyCmpInternal). Can someone rerun the benchmark, preferable not on amd64? If we do this, the (somehow weird) escaped slash:
could also yield correct order. (It would be interpreted as text and not as delimiter.) The question if is this feature was a good idea after all (its already ancient). |
Values from my development machine (VMware VM running 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3+deb7u2 x86_64 GNU/Linux). Host CPU is Intel Core i5-2520M
Values from a 32-bit Server-VM follow as soon as #60 is fixed. |
thank you, I think thats ok for now. |
Values from a server I run (KVM VM running 2.6.32-5-486 i686 GNU/Linux). Host CPU is Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
|
Will solve this by having a keyName that has double length. @fberlakovich Please use keySetRawName() internally, so that this issue can be solved on a single place. |
Where should I use |
Nevermind, I just found where I should use it. However, it still does not exist yet? |
No, it does not exists yet |
Ok, after finishing the changes on keyAddBaseName and keySetBaseName I am afraid I won't have enough time to also do this refactoring. As it turns out, there are a lot of things (at least testcases) that have to be adjusted to the new specification. |
You do not have to adapt the existing test cases. Then I can decide case by case if it is actually a change of behaviour or if it fixes a problem. So please concentrate on the implementation, refactoring and adding new tests that are missing. |
Ok, as you can see in the pull request I provided a quickfix for everything that was obviously broken and fixed the tests that should still work. However, some tests contradict the new specificaiton. I disabled them and added a TODO. |
also in binding refactor with elektraFinalizeName as preparation for fixing #38 fail when no key is there before for adding functions fix tests that try to do that refactor keySetName to use keyAddName internally do keyAddBaseName and keySetBaseName both with escaping comment out KEY_FLAG_RO_NAME because some tests fail with it fix mounting with config to properly add conf that contains /
I recently sumbled over the following problem a couple of times. I am not quite sure yet however if this is actually a bug or something on my system is broken.
My guess: if two mountpoints are created where the name of the one is a prefix of the other, the shorter mountpoint is no longer accessible. Example:
Up to now it works as expected. Now i do
This still works as expected. But now a
kdb ls system/foo
won't return any results anymore. A look intosystem/elektra/mountpoints
reveals, that the keysystem/elektra/mountpoints/foo
and its subkeys are not sorted continously anymore. Instead the order isI suspect that this causes the problem, but I have not looked into the mount code in detail yet.
The text was updated successfully, but these errors were encountered: