Btrfs File-System Updates Land In Linux 5.7

[SystemCrasher]

- Preparation for zoned device support.

Well, - btrfs way: plug it in and it works just fine, with very little fuss. - RH/xfs way: throw bizarre rituals, use dozen of management tools & layers or scary shithoncrust crap tooling, coded by cheap RH webmonkeys to deal with all that insane garbage. And if it falls apart go call RH support, since you'll be unable to fix that trash anyway.

[dragon321]

i'd also choose that extension, which still wouldn't stop .C files from being c++ sources

Compiler doesn't care about extension. Most C++ projects use "h" extension for headers which is C extension.

[pal666]

Nah thanks, I think I will stay with "cpp" extension for C++ sources.

i'd also choose that extension, which still wouldn't stop .C files from being c++ sources

[oleid]

Properly supporting Unicode case insensitivity would make it slow as well.
Do we know how windows does that? Does it only support ascii insensitivity?

[dragon321]

because a.c is a c source, but a.C is a c++ source

Nah thanks, I think I will stay with "cpp" extension for C++ sources.

because "Letter.txt" and "letter.TXT" are different Just look:

P.S. of course you should not. Just do whatever makes you happy

I'm aware that their names are different strings for computer. I just asked why it should be also different for me.

I think case insensitive should be optional, not mandatory. To make more users happy.

Case insensivity is easy, as long as you restrict yourself to ASCII. When using unicode, that is a whole different thing. Even for not totally different languages like German, there are letters which require complicated mapping. E.g. straße and STRAẞE. Actually, the big variant of "ß" is not often used (people usally don't shout) and often it is even spelled as STRASSE. So you would need to support ß ~ SS = ẞ.

So in essence, I'm _personally_ not sure if it should be really in kernel at all.

Where it should land then? It's filesystem thing and on Linux filesystems are kernel code. Adding additional layer in user space would make this slow.

[skeevy420]

To the people suggesting other options, it's because I think using "chattr +F /my_dir" is easier than the various image and mount strategies. It's a handy tool to have in the bag and one you might not realize you like or miss until it isn't there

[oleid]

Why I should treat "Letter.txt" and "letter.TXT" as totally different files?

Case insensivity is easy, as long as you restrict yourself to ASCII. When using unicode, that is a whole different thing. Even for not totally different languages like German, there are letters which require complicated mapping. E.g. straße and STRAẞE. Actually, the big variant of "ß" is not often used (people usally don't shout) and often it is even spelled as STRASSE. So you would need to support ß ~ SS = ẞ.

So in essence, I'm _personally_ not sure if it should be really in kernel at all.

[Nth_man]

As Panzi (Panzenböck) wrote:

In Unicode you can write letters like ö in 2 different ways: as NFD (2 codepoints) or NFC (1 codepoint). Are they the same file name? For crappy (=basically all) American and UK systems I have to write my last name as Panzenboeck instead of Panzenböck. Is that the same file name?

Although in the case of playing Windows games, miming Windows behavior helps there.

[Nth_man]

As it was already written in other place:

"Case" is not a universal language construct. It's meaningless to do a case-insensitive compare of Arabic, for example.

Wanting magical "do what I want, not what I say" behavior in a filesystem is already dangerous enough, having that behavior hinge on the character set is even worse.

[lucrus]

Not to say that Windows games aren't important, but there seem to be even more compelling reasons to support case insensitivity (casefold to be precise): gotta love oiaohm for the wonderful explanations: https://www.phoronix.com/forums/foru...e2#post1097790