Path Length Limit on Windows

GetFullPathNameA [1] (A for Ansi, W for Wide which is now known as Unicode), works with both the dos 8.3 filename and long file path structure and long filenames.

Manifests are not necessary, but then some API's wont return the right data, it will assume its stuck at Win8.1, when it could be leveraging the api's on more recent versions of Windows. Manifests could be viewed like a way to configure your app's functionality in a sandbox.

Admittedly the Win api docs can be a bit misleading but this is rare, something only seasoned devs will spot, but there isnt anything I cant do on NTFS which I couldnt do on other filesytstems.

By default the file paths (directorys) are not case sensitive, but a simple reg entry later (or command of sorts as there are many ways to changes settings) and I can make the FS case sensitive just like many nix FS's are out of the box.[2,3]

With the new OS's its all long filenames, so depending on the API used, you might see the old dos8.3 filename name returned, but more often than not especially with newer api's being used, you wont see the 8.3 format.

And to make that interesting enough, you can also use transacted api's to speed things up a bit more and have that extra control over windows which is useful for High Resolution Time functions [4]. This was introduced when the London Stock Market tried to use windows as its trading platform and it reportedly failed, so MS introduced these changes, which could please some high frequency traders.

The reserved names you mention is because MS is pro active at supporting code written using api's from decades ago, these harp back to the dos days as well, its backward's compatibility on display.

>:, allowed in Linux, is a filestream or drive letter signifier on NTFS.

The concept of a drive letter to represent a partition is a MS feature which is why the : is not allowed in windows. In nix world, drive letters dont feature out of the box so thats why the colon can be used.

>'file ' with a space at the end of the name, that's a no no here too.

Cstrings aka null terminated strings for filenames, what a pain in the backside it would be if you could have filenames and folders with an unlimited number of trailing spaces...

'File ' (1 trailing space)

'File ' (2 trailing spaces)

'File ' (3 trailing spaces)

'File ' (4 trailing spaces)

Why would you want that? Is this some sort of IT mental bondage or something stealthily hidden away in the *nix world?

In the blog post itself, the section on Directory traversal does not mention anything about the group policy setting which is off by default, but could be used to restrict directory traversal [5]. Again if you dont know your windows OS, this GPO will cause problems to dev's who dont know about securing a windows machine. A well written windows app can test the security settings of the machine in very subtle ways to work out just how good a business or individual has locked down their machine.

> Despite the long path support in Windows and efforts like this, it will take “at least” very long before one could reliably rely on paths longer than 260 characters on Windows. Prevention will thus probably remain the key part of the solution for a long time.

When reading this blog post, I think the R developers are catering for the lowest common denominator, namely older API's. It can be tricky choosing what API's to use if you dont know your intended audience, for example, do you write one app knowing it will run on every OS from W2k to Win11, or you do you write two apps, one for Win2k-Vista and one for Vista-Win11 or Win2k-Win8.1 and one for Win 8.1-Win11?

So many changes have occurred, but it might not even apply because the api's used are not affected. However these win API changes do give insights into the area's MS have been concentrating effort on, and also highlight potential exploits, just like WannaCry exploited SMB1.

[1] https://learn.microsoft.com/en-us/windows/win32/api/fileapi/...

[2] https://devblogs.microsoft.com/commandline/per-directory-cas...

[3] HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\obcaseinsensitive

[4] https://learn.microsoft.com/en-us/windows-hardware/drivers/k...

[5] https://learn.microsoft.com/en-us/windows/security/threat-pr...