e2p: Print encoding information in superblock dump
PATCH 1/1 e2p: Print encoding information in superblock dump
Display encoding related fields when printing superblock in places like dumpe2fs or debugfs.
--- lib/e2p/e2p.h | 1 + lib/e2p/encoding.c | 10 ++++++++++ lib/e2p/ls.c | 44 ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 55 insertions(+)
lib/e2p/e2p.h +1 -0
@@ -84,3 +84,4 @@ int e2p_string2encmode(char *string);int e2p_str2encoding (const char *string);int e2p_get_encoding_flags (int encoding);int e2p_str2encoding_flags (int encoding,char *param,__u16 *flags); +char *e2p_encoding2string (int encoding);
lib/e2p/encoding.c +10 -0
@@ -61,6 +61,16 @@ int e2p_str2encoding(const char *string)return -EINVAL ; } +char *e2p_encoding2string (int encoding) +{ +int i; + +for (i =0 ; i <ARRAY_SIZE (ext4_encoding_map); i++) +if (ext4_encoding_map[i].encoding_magic == encoding) +return ext4_encoding_map[i].name; +return NULL ; +} +int e2p_get_encoding_flags (int encoding) {int i;
lib/e2p/ls.c +44 -0
56 lines not on this page · raw message
Signature · 1 line
2.20.0.rc2
lib/e2p/ls.c
Quoted 4 lines · Gabriel Krisman Bertazi
lib/e2p/ls.c +0
-0
....
lib/e2p/ls.c static void print_mntopts(struct ext2_super_block * s, FILE *f) · line 167
Quoted 13 lines
lib/e2p/ls.c +13
-0+if (encoding ==EXT4_ENC_UTF8_11_0 ) { +if (flags &EXT4_UTF8_NORMALIZATION_TYPE_NFKD ) +fputs (" NFKD" , f); +else +fputs (" Unnormalized" , f); + flags_found++; + +if (flags &EXT4_UTF8_CASEFOLD_TYPE_NFKDCF ) +fputs (" NFKDCF" , f); +else +fputs (" toUpper" , f); + flags_found++; + }
I don't understand this. Why is "toUpper" the opposite of "CASEFOLD_TYPE_NFKDCF"? From what I can tell looking at the kernel patches, it appears that if CASEFOLD_TYPE_NFKDCF is not specified, no case folding is done at all. And it appears the opposite of "toupper" is "tolower" --- for ASCII case folding.
More generally, we don't have a way of setting these flags, and I'm wondering if we should just make a decision and be done with it. After all, without any way of changing the flags, there's only one code path that is going to be well tested, and realistically user programs will come to *expect* only one way file systems will do things. The MacOS world has discovered the hard way what happens if they try to change normalization conventions from one to another, leading to all sorts of confusion for application programmers.
So perhaps we should just remove these flags from the superblock, and only support one way of doing things. We ask the opinion of various stake-holders --- the Samba folks, fsdevel, Steam, etc. But whether we decide NFC, NFD, NFKC or NFKD, I suspect we'll be better off just
picking one and only one way of doing things. WDYT?
- Ted
Quoted 17 lines · Theodore Y. Ts'o
lib/e2p/ls.c
Quoted 4 lines · Gabriel Krisman Bertazi
lib/e2p/ls.c +0
-0....Quoted 11 lines
lib/e2p/ls.c +11
-0+if (encoding ==EXT4_ENC_UTF8_11_0 ) { +if (flags &EXT4_UTF8_NORMALIZATION_TYPE_NFKD ) +fputs (" NFKD" , f); +else +fputs (" Unnormalized" , f); + flags_found++; + +if (flags &EXT4_UTF8_CASEFOLD_TYPE_NFKDCF ) +fputs (" NFKDCF" , f); +else +fputs (" toUpper" , f);
Quoted 8 lines
lib/e2p/ls.c
Quoted 2 lines
lib/e2p/ls.c +2
-0+ flags_found++; + }I don't understand this. Why is "toUpper" the opposite of "
CASEFOLD_TYPE_NFKDCF"? From what I can tell looking at the kernel patches, it appears that ifCASEFOLD_TYPE_NFKDCFis not specified, no case folding is done at all. And it appears the opposite of "toupper" is "tolower" --- for ASCII case folding.
In order to allow any NLS charset to benefit from the nls_strcmp/strncasecmp API I specified some default normalization/casefold operations that could be implemented using the hooks we already have. The default was toUpper. That was my thinking. utf8 was originally split between utf8 and utf8n, the former being the original unnormalized behavior. If we didn't have CASEFOLD_TYPE_NFKDCF, it used the toUpper method.
Quoted 9 lines
More generally, we don't have a way of setting these flags, and I'm wondering if we should just make a decision and be done with it. After all, without any way of changing the flags, there's only one code path that is going to be well tested, and realistically user programs will come to *expect* only one way file systems will do things. The MacOS world has discovered the hard way what happens if they try to change normalization conventions from one to another, leading to all sorts of confusion for application programmers.
Quoted 5 lines
So perhaps we should just remove these flags from the superblock, and only support one way of doing things. We ask the opinion of various stake-holders --- the Samba folks, fsdevel, Steam, etc. But whether we decide NFC, NFD, NFKC or NFKD, I suspect we'll be better off just
picking one and only one way of doing things. WDYT?
My approach is over-complex, just to support the existing NLS tables. Since Linus seems ok to move the code into a separate module and not support other encodings, I agree we can make things much simpler, define a single normalization/casefold and be done with it.
So, I will revive the first versions of this charset/unicode module. We drop these flags from the superblock, but we still store the encoding and the encoding version in it, since it is useful to maintain stability of name sequences. We also support ASCII, alongside with utf8 because that is a safer and pretty trivial. Finally, do we revisit the decision to provide a strict mode to reject invalid sequences? I still think that flag is useful. Do we also want a flag to specify if the default is +F for newer directories?
Do you agree?
Signature · 1 line
Gabriel Krisman Bertazi