Linux 5.18 Makes Two Key Improvements To exFAT File-System Support

[phoronix]

Phoronix: Linux 5.18 Makes Two Key Improvements To exFAT File-System Support

Ahead of the Linux 5.18 merge window ending this weekend, the driver for Microsoft's exFAT file-system saw its pull request today. There are just two patches this cycle for exFAT but both changes are significant...

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.18-exFAT

[Danny3]

Nice!
But pretty strange that trailing dots were not allowed.
I understand that trailing slashes (/) could be a problem, but dots?

I wonder if any work has been done on the the new NTFS driver too since it was merged in?
I haven't heard anything anymore about it and I'm curios if any work has been done to make it in the future the default driver instead of the NTFS-3G.

[Vorpal]

I assume the trailing dot thing may be a Windows limitation on file names? Along the lines of not allowing CON and LPT1 (among a myriad of other things).

The restrictions on file names on Linux and BSDs (and maybe other *nix too, not sure) is so much simpler, at least traditionally. Null byte and ascii forward slash are prohibited. That's it. Single dot and double dot could arguably be said to be reserved as well, but you could also make the argument that those entries just automatically exist in each directory and are thus not reserved, just already in use.

Of course with the new case insensitive options for ext4 etc that may no longer be true, haven't looked into that. Does that depend on unicode normalisation? Does the kernel care about encoding suddenly?

[birdie]

Windows does not allow files to end filenames with dots. Good luck then using your exfat flash drive with Windows PCs.

[bug77]

I assume the trailing dot thing may be a Windows limitation on file names? Along the lines of not allowing CON and LPT1 (among a myriad of other things).

Are they really disallowing those? Because I remember some time ago I was actually able to create a folder named like that. Getting rid of it was a different story, though

[oiaohm]

Windows does not allow files to end filenames with dots. Good luck then using your exfat flash drive with Windows PCs.

https://github.com/bazelbuild/bazel/issues/2173

Welcome to being wrong again birdie. There is a reason why the wine project has a test windows to validate what real functionality is because windows documentation is wrong so often wrong or easy to read wrong.

Windows createfile function does prevent you to from creating a file ending with dots this is correct. But as the person who decided to test windows found out with cygwin that the cygwin touch program due to the function it uses can under windows create files ending with dots on NTFS and exfat and fat32.

There are a lot of thing incorrectly implemented in windows. MSDN documentation takes some careful reading.

https://docs.microsoft.com/en-au/win...ng_conventions.

Do not end a file or directory name with a space or a period. Although the underlying file system may support such names, the Windows shell and user interface does not. However, it is acceptable to specify a period as the first character of a name. For example, ".temp".

This is the real state of the nightmare is written in the MSDN if you read it carefully. If you could not under windows create files ending with period/dots they would not have to include instruction in the MSDN to not do create files ending with dots/periods. Yes there is a critical note here that the Windows Shell and other parts are not validated with files ending with period/dots.

Yes all those do not instructions in this section of the MSDN refer to something a developer/user could really do under windows that is going to be quirky for the user.

Do not use the following reserved names for the name of a file:

CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. Also avoid these names followed immediately by an extension; for example, NUL.txt is not recommended. For more information, see Namespaces.

Yes this do not is the same that you can in fact under windows create all those file names on a file system using the right functions. This one will work with the windows shell fairly much safely but will not work with the Windows command line. The ending in dot/period works with the windows command line but not with the graphical shell. Combine the two create a true totally screwed. The reality is either of the two do not instructions I have reference in the MSDN alone don't make it impossible to use the drive under windows just makes it quirky that you must interface with the drive a particular way or it does not work for you.

So its not good luck using exfat with dots on the end of file name under windows because it totally works using the right methods. The problem is using the wrong methods things are going to be strange quirky/crashy....

Birdie with windows there is a difference between not recommended and not allowed. Yes dots/period on end of filenames with windows is only not recommend you can do it if you willing to put up with different areas of windows not working right. There are a lot of things people say are not allowed under windows that after closer inspection by running a few tests that also turn out to be this not recommend instead this has made wine development very complex at times when you find game developers and other parties using these not recommend things in anti-cheat and tamper resistance.

[birdie]

wall of text

God damn it.

Such files will be unusable under Windows. You said I was wrong then wrote the wall of text proving me right. And it's almost always like that, you always object to what I'm saying then post walls of text which basically prove my POV from the implementation perspective.

In Windows Explorer and most applications using standard Win32 APIs you cannot open such files, OK? Enough? The fact that NTFS supports them does not mean shit if such files cannot be opened.

[birdie]

What's more the Linux kernel does not even allow to create files ending with a dot or space on exfat/fat32 volumes.

You may do that for NTFS but under Windows both files will be unreadable.

You are so fucking great at theorizing, as usual.

[Ladis]

You may do that for NTFS but under Windows both files will be unreadable.

Are they really unreadable or only in that one program (FAR)? I would expect testing directly in the command line. Also - maybe just for me - when someone has to bolden part of their text, it loses its argumantation value.

[oiaohm]

God damn it.In Windows Explorer and most applications using standard Win32 APIs you cannot open such files, OK? Enough? The fact that NTFS supports them does not mean shit if such files cannot be opened.

This is not 100 percent true. Its quirky if it will or will not open. It will depend what Win32 API the application is using. Windows Explorer as long as you don't have like you had with "testfil" and "testfil." in the same directory the thing works. Yes Windows Explorer just goes and ignores that the filename or directory has a dot and accesses it anyhow of course to the user it looks like they opened "testfil" when on the file system its "testfil.".

What's more the Linux kernel does not even allow to create files ending with a dot or space on exfat/fat32 volumes.

https://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat.git/commit/?h=dev&id=9ec784bf774c2d3b35a7577fc6441cfbd60aefea

This is true the new patch is only that you can access files with dot on end not go ahead and create more of the evil issue. Reason why Linux kernel is adding means to-do this is because it valid for a exfat partition that windows will read to have file names and directory name end with a "dot".

Of course this is valid from user point of view that they put the exfat formated usb key into windows and they could access the file then they put it into Linux and it does not work so Linux is broken right. Of course the user is missing that the dot on end of filename or path is broken and that they could in one miss action possible lock themselves out of their files under Windows.

You may do that for NTFS but under Windows both files will beunreadable.

Do note I said quirky. You had a file with a dot on the end and a file without a dot on the end of the same name in the same directory. Yes you are right both file are unreadable from some windows APIs not all. Its a different matter they are in different directories right where it works. This is quirky.

birdie it worse than that there are some cheap digital cameras that all files and directories they create on exfat have a dot on the end. Yes these memory cards work Okish in windows because you don't have 2 file that to windows appears to some windows API of exactly the same file name.

Yes the example of both files in the same directory making both files unreadable this does also make the files unreadable to quite a few antivirus solutions.

Gets very interesting when you put the EICAR test file in a file that has a dot end duplicate next to it some anti-virus products detect it others don't. Yes there are ways using particular windows API to read the contents of the files with the quirk issue you hit.

birdie I did say anti-cheat and tamper resistance in some software use this quirks. Malware also uses these quirks at times to avoid detection.

Quirky is horrible area to be. Sorry birdie you are still wrong here problem here is dot ending files and directories are in fact accessible under windows there are quirks that result in files come not accessible under windows so you don't want to be creating files with dot on end to protect user from their own stupidity.

My wall of text was not proving you right. Instead it was point out there is a quirk here. The way Microsoft documentation is written is because there is quirk you can do this under windows it will work some of the time. Problem some of the time. Lets say you have in two directories with "testfil" in one and "testfil." you have been working on both and go to copy testfil or testfil. into the other directory from windows shell they look same after you copy the files then you find out hang on one had a "dot" now both are not accessible to the program I am using.

The reality here there is a bug in Windows file handling here that can come and get you.