9 ms·

What I personally find more egregious are dotfiles and dot-dirs on Windows, created by half-baked ports of Unix-first software (such as `ssh`). Windows has `%A

What I personally find more egregious are dotfiles and dot-dirs on Windows, created by half-baked ports of Unix-first software (such as `ssh`). Windows has `%APPDATA%` and `%LOCALAPPDATA%` that are accessible with `ShGetKnownFolderPath`[0], using the appropriate `KNOWNFOLDERID`[1]; all programs should put their configuration and cache data in these paths. Windows also doesn't know what the dot at the beginning of a file/folder means. Instead, it and NTFS have something that's arguably better: a hidden file attribute `FILE_ATTRIBUTE_HIDDEN`[2], that's again settable/gettable when a file/directory is created or polled, rather than regex-ing for a full-stop. The worst irony is Microsoft software creating dot-files and dot-dirs on Windows[3][4][5]. [0]: https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetknownfolderpath https://learn.microsoft.com/en-us/windows/win32/api/shlobj_c... [1]: https://learn.microsoft.com/en-us/windows/win32/shell/knownfolderid https://learn.microsoft.com/en-us/windows/win32/shell/knownf... [2]: https://learn.microsoft.com/en-gb/windows/win32/api/fileapi/nf-fileapi-setfileattributesa?redirectedfrom=MSDN https://learn.microsoft.com/en-gb/windows/win32/api/fileapi/... [3]: https://github.com/dotnet/sdk/issues/8678 https://github.com/dotnet/sdk/issues/8678 [4]: https://github.com/OmniSharp/omnisharp-roslyn/issues/953 https://github.com/OmniSharp/omnisharp-roslyn/issues/953 [5]: https://github.com/microsoft/vscode/issues/3884 https://github.com/microsoft/vscode/issues/3884

CGamesPlay 4y ago
Is “..” the official way to get a parent directory on Windows? Or do they have some other API and the “..” is just a nod to UNIX compatibility?
- wruza 4y ago
  Hold your giggles until you learn that windows MAX_PATH is only 260 characters. Not just filename, the entire path. Unless an app uses \\?\ prefixes and special API for navigation, which is rare, ime.
- metadat 4y ago
  ".." works fine in Windows environments.
- delta_p_delta_x 4y ago
  > on Windows There are many ways to access the filesystem on Windows. CMD.exe and PowerShell respect `..` to go to the parent directory, as does MSVC C++17 with `std::filesystem`, and .NET, with `System.IO.Path.Combine(String, String)`. In PowerShell and .NET, there's also the `System.IO.DirectoryInfo.Parent` property, and of course, the equivalent `std::filesystem::path::parent_path` in MSVC C++.
  - TeMPOraL 4y ago
    There's an important consideration 'ChrisSD mentions here[0], i.e. whether resolving ".." is done lexically or by querying the filesystem. You may get different answers in each case if e.g. you try to resolve /foo/bar/../baz, when /foo/bar is a symlink to a different directory. At least in case of std::filesystem, everything in std::filesystem::path is purely lexical. So, to get actual parent of some path, you'll need to go through std::filesystem::directory_entry and std::filesystem::read_symlink(). -- [0] - https://news.ycombinator.com/item?id=33312712 https://news.ycombinator.com/item?id=33312712
- ChrisSD 4y ago
  The difference between Windows ".." and unixy ".." is that the former is done lexically whereas the latter is a link to the canonical parent. E.g. on Windows: "path\to\..\file" is always the equivalent of "path\file". Whereas on unixy systems "path/to/../file" may take you to a completely different parent directory. That said, Unix shells can muddy the waters a bit. They may choose to act lexically with some commands.
  - rollcat 4y ago
    > E.g. on Windows: "path\to\..\file" is always the equivalent of "path\file". Whereas on unixy systems "path/to/../file" may take you to a completely different parent directory. Worth noting here that Plan 9 is using lexical names[1], and the Go standard library offers the function path.Clean[2] to achieve similar results. If your language/library/OS doesn't offer this behavior by default, it's likely a good idea to add/reimplement this function, unless you need bug-for-bug compatibility. [1]: https://web.archive.org/web/20220824070659/https://9p.io/sys/doc/lexnames.html https://web.archive.org/web/20220824070659/https://9p.io/sys... [2]: https://golang.bg/pkg/path/#Clean https://golang.bg/pkg/path/#Clean
- wizofaus 4y ago
  It seems the only official native API for getting the parent directory from a known (full) path is PathCchRemoveFileSpec. But certainly C# and other similar platforms have functions doing similar things, and usually don't require a system API call anyway, it's just string manipulation - unless of course the path is relative to the current directory.
avsteele 4y ago
When using .Net 6 I use Environment.GetFolderPath( SpecialFolder.LocalApplicationData) in Windows this maps to ~/AppData/Local An in Linux to ~/.local/share so it is configured well
- viraptor 4y ago
  I'm not sure I'd call that configured well. On Linux, share is supposed to contain static data used by the app, not the changing configuration that normally goes into appdata on Windows. For config the equivalent should be ~/.config/appname
  - ziml77 4y ago
    He's getting the wrong folder on Windows too because that's what he's requesting when passing in SpecialFolder.LocalApplicationData. SpecialFolder.ApplicationData returns %USERPROFILE%\AppData\Roaming on Windows and ~/.config on Linux.
deburo 4y ago
On Windows anyway, the root of the user profile is already filled with garbage directories, and so a few more dot-dirs and files feel par for the course. The advantage is that accessing your root dir is easier than typing out %appdata% in File Explorer.
- delta_p_delta_x 4y ago
  One could say the same for ~ on Linux. 'It's already bad' isn't an excuse for sloppy programming. Software should ideally adhere to OS norms. Better still, software shouldn't be opaque about where global/user-specific cache/config data is stored, and should prompt users to choose (or set sane defaults, again adhering to OS norms). IMO the video game industry is a big offender of home-folder pollution, with saves and configs being splattered all over %USERPROFILE%\Documents, %USERPROFILE%\My Documents\ (which is a legacy holdover from Windows XP), %USERPROFILE%\Saved Games (which does have a corresponding KNOWNFOLDERID), etc etc.
  - toastal 4y ago
    If it's any consolation, games from Steam on Linux leak files all over the place on that OS too. Right now the offenders in my $HOME not following $XDG are games, LibreWolf via Mozilla, Xmonad, GnuPG, and anything related to npm (with their maintainers closing any issued opened about support $XDG).
  - Macha 4y ago
    SteamApps/userdata, %APPDATA%/Publisher, %APPDATA/Developer, %LOCALAPPDATA%, the list goes on...
  - rogual 4y ago
    When making games, I have them store their config in %APPDATA% on Windows, although I do see the downside if there's a bug and I want to direct a customer to send me a log file that was saved there or just generally delete or move files around in there. It's not as familiar and safe-feeling for a nontechnical user to navigate to %APPDATA% is it is to just look in their Documents.
bbkane 4y ago
I prefer the app placing the config in the same place on every system. It makes it easier for me to find the file regardless of OS (to modify or back up with a script) and it's simpler for the app dev to write the code for as well. I recognize this is probably because I first learned about config files on a Unixy system, it's not the "native way" for Windows, and other people have stronger cases for their preference, but this is my preference and I'm stickin to it :)
- delta_p_delta_x 4y ago
  Your argument breaks down even between 'Unixy' systems. Linux programs that follow the XDG base directory specification write to those, whereas macOS programs tend to write to ~/Library/Preferences or ~/Library/Application Support, neither of which exist on Linux, or even BSDs. When in Rome, do as the Romans do.
  - wruza 4y ago
    I’m a Roman and have no clue what these AppData/Romaning are for. Dotfiles that I’m aware of are my files and I expect them to reside in my ~ atrium.
  - klibertp 4y ago
    > When in Rome, do as the Romans do. Yeah, but then again, when you visit Rome for a short vacation as a tourist, the English versions of menus and such help, no? Just saying, some degree of consideration for non-natives is a good thing, as it will help the tourism business generate more revenue. Same for OSes: give me at least an option of staying with my old habits until I get used to the new ones, then there's a higher chance I'll switch.
- codedokode 4y ago
  > I prefer the app placing the config in the same place on every system. That is impossible because in Linux there is no drive letters and you cannot have the same path to a file as in Windows.
matheusmoreira 4y ago
I don't find it egregious at all. Nobody should go out of their way to integrate with Windows APIs when files work just fine everywhere.
- Spivak 4y ago
  It’s basically the same as looking up $XDG_CONFIG_HOME on GNU/Linux.
  - matheusmoreira 4y ago
    That's just an environment variable while this ShGetKnownFolderPath thing is a Win32 API function. People should avoid directly depending on that stuff as much as possible. People aren't obligated to "comply" with the XDG specification either. It's not a bug to just use $HOME.
    - pie_flavor 4y ago
      You're directly depending on platform-specific stuff the moment you look up the user directory, because it's not $HOME on Windows either. There is a difference between being cross-platform, and being Linux but mangling it so it technically works on other platforms.
      - matheusmoreira 4y ago
        It's just a different variable: USERPROFILE. https://stackoverflow.com/a/42700844/512904 https://stackoverflow.com/a/42700844/512904 > being Linux but mangling it so it technically works on other platforms Sounds like the easiest way to solve this problem. I don't blame or shame developers for choosing it. This is simple and works everywhere: char * home = getenv("USERPROFILE"); if (home) { // Use home directory } The answer demonstrating the Windows API way has the following code to accomplish the same thing: WCHAR profilePath[MAX_PATH]; HRESULT result = SHGetFolderPathW(NULL, CSIDL_PROFILE, NULL, 0, profilePath); if (SUCCEEDED(result)) { // Use home directory } Yeah, I seriously doubt open source developers want to deal with this Windows bullshit. I sure don't. Maybe if you're getting paid.
codedokode 4y ago
I think "hidden" files are a bad idea. What's the point of hiding some of the files in a directory from user? It only makes things more confusing. For example the folder might look empty but in fact it could contain thousands of hidden files. You want to delete it as it is empty but accidentally delete important system files. Even worse, imagine if all files on an USB drive are marked as hidden. You see that the drive is empty but when you attempt to copy something to it see a message that there is no free space. One more example. Imagine if you have a project and want to edit an .env file. But as dotfiles are hidden in Linux you don't see this file and cannot open it. It turns out that Windows Explorer which doesn't hide dotfiles is much better for developing projects with Docker! There should be no hidden files. We cannot do anything with Windows and their MS-DOS legacy but Linux could stop hiding dotfiles in GUI and CLI commands.
- 8n4vidtmkvmk 4y ago
  i just always list dotfiles for years now.. and my IDEs too. mostly a non issue.
  - codedokode 4y ago
    And I have to enable showing them on every system I work with (and add -a to every ls command, and google which option enables incldues them in pattern expansion). That is annoying.
    - 8n4vidtmkvmk 4y ago
      Well.. ya. I set up my aliases and then forget about it again. Globbing is mildly annoying but i think there's a dotglob option or something you can set
- klodolph 4y ago
  Hidden files on MacOS were used sparingly—the main instance of a hidden file is the file which stores an icon for a folder, if the folder has a custom icon. Hidden files are only hidden from the UI, they appear normally in the command line. The standard Unix folders (usr, var, etc) are also hidden—to be honest, this is a compromise because the Unix filesystem hierarchy sucks, but we are saddled with it for backwards compatibility reasons. I did appreciate the relative clarity of old macOS systems—everything in the OS was in “System Folder”, the rest of the filesystem was yours, and you could freely move applications without breaking anything, uninstall them by putting them in the trash, etc.
rozab 4y ago
Windows is a lost cause anyway. Even Microsoft products (at a glance: IISExpress, Visual Studio, RDP, Powershell) happily dump their cruft in the Documents folder. I don't know where they imagine users should actually save the files they control.

CGamesPlay 4y ago

Is “..” the official way to get a parent directory on Windows? Or do they have some other API and the “..” is just a nod to UNIX compatibility?

wruza 4y ago
Hold your giggles until you learn that windows MAX_PATH is only 260 characters. Not just filename, the entire path. Unless an app uses \\?\ prefixes and special API for navigation, which is rare, ime.
metadat 4y ago
".." works fine in Windows environments.
delta_p_delta_x 4y ago
> on Windows There are many ways to access the filesystem on Windows. CMD.exe and PowerShell respect `..` to go to the parent directory, as does MSVC C++17 with `std::filesystem`, and .NET, with `System.IO.Path.Combine(String, String)`. In PowerShell and .NET, there's also the `System.IO.DirectoryInfo.Parent` property, and of course, the equivalent `std::filesystem::path::parent_path` in MSVC C++.
- TeMPOraL 4y ago
  There's an important consideration 'ChrisSD mentions here[0], i.e. whether resolving ".." is done lexically or by querying the filesystem. You may get different answers in each case if e.g. you try to resolve /foo/bar/../baz, when /foo/bar is a symlink to a different directory. At least in case of std::filesystem, everything in std::filesystem::path is purely lexical. So, to get actual parent of some path, you'll need to go through std::filesystem::directory_entry and std::filesystem::read_symlink(). -- [0] - https://news.ycombinator.com/item?id=33312712 https://news.ycombinator.com/item?id=33312712
ChrisSD 4y ago
The difference between Windows ".." and unixy ".." is that the former is done lexically whereas the latter is a link to the canonical parent. E.g. on Windows: "path\to\..\file" is always the equivalent of "path\file". Whereas on unixy systems "path/to/../file" may take you to a completely different parent directory. That said, Unix shells can muddy the waters a bit. They may choose to act lexically with some commands.
- rollcat 4y ago
  > E.g. on Windows: "path\to\..\file" is always the equivalent of "path\file". Whereas on unixy systems "path/to/../file" may take you to a completely different parent directory. Worth noting here that Plan 9 is using lexical names[1], and the Go standard library offers the function path.Clean[2] to achieve similar results. If your language/library/OS doesn't offer this behavior by default, it's likely a good idea to add/reimplement this function, unless you need bug-for-bug compatibility. [1]: https://web.archive.org/web/20220824070659/https://9p.io/sys/doc/lexnames.html https://web.archive.org/web/20220824070659/https://9p.io/sys... [2]: https://golang.bg/pkg/path/#Clean https://golang.bg/pkg/path/#Clean
wizofaus 4y ago
It seems the only official native API for getting the parent directory from a known (full) path is PathCchRemoveFileSpec. But certainly C# and other similar platforms have functions doing similar things, and usually don't require a system API call anyway, it's just string manipulation - unless of course the path is relative to the current directory.

avsteele 4y ago

When using .Net 6 I use Environment.GetFolderPath( SpecialFolder.LocalApplicationData) in Windows this maps to ~/AppData/Local An in Linux to ~/.local/share so it is configured well

viraptor 4y ago
I'm not sure I'd call that configured well. On Linux, share is supposed to contain static data used by the app, not the changing configuration that normally goes into appdata on Windows. For config the equivalent should be ~/.config/appname
- ziml77 4y ago
  He's getting the wrong folder on Windows too because that's what he's requesting when passing in SpecialFolder.LocalApplicationData. SpecialFolder.ApplicationData returns %USERPROFILE%\AppData\Roaming on Windows and ~/.config on Linux.

deburo 4y ago

On Windows anyway, the root of the user profile is already filled with garbage directories, and so a few more dot-dirs and files feel par for the course. The advantage is that accessing your root dir is easier than typing out %appdata% in File Explorer.

delta_p_delta_x 4y ago
One could say the same for ~ on Linux. 'It's already bad' isn't an excuse for sloppy programming. Software should ideally adhere to OS norms. Better still, software shouldn't be opaque about where global/user-specific cache/config data is stored, and should prompt users to choose (or set sane defaults, again adhering to OS norms). IMO the video game industry is a big offender of home-folder pollution, with saves and configs being splattered all over %USERPROFILE%\Documents, %USERPROFILE%\My Documents\ (which is a legacy holdover from Windows XP), %USERPROFILE%\Saved Games (which does have a corresponding KNOWNFOLDERID), etc etc.
- toastal 4y ago
  If it's any consolation, games from Steam on Linux leak files all over the place on that OS too. Right now the offenders in my $HOME not following $XDG are games, LibreWolf via Mozilla, Xmonad, GnuPG, and anything related to npm (with their maintainers closing any issued opened about support $XDG).
- Macha 4y ago
  SteamApps/userdata, %APPDATA%/Publisher, %APPDATA/Developer, %LOCALAPPDATA%, the list goes on...
- rogual 4y ago
  When making games, I have them store their config in %APPDATA% on Windows, although I do see the downside if there's a bug and I want to direct a customer to send me a log file that was saved there or just generally delete or move files around in there. It's not as familiar and safe-feeling for a nontechnical user to navigate to %APPDATA% is it is to just look in their Documents.

bbkane 4y ago

I prefer the app placing the config in the same place on every system. It makes it easier for me to find the file regardless of OS (to modify or back up with a script) and it's simpler for the app dev to write the code for as well. I recognize this is probably because I first learned about config files on a Unixy system, it's not the "native way" for Windows, and other people have stronger cases for their preference, but this is my preference and I'm stickin to it :)

delta_p_delta_x 4y ago
Your argument breaks down even between 'Unixy' systems. Linux programs that follow the XDG base directory specification write to those, whereas macOS programs tend to write to ~/Library/Preferences or ~/Library/Application Support, neither of which exist on Linux, or even BSDs. When in Rome, do as the Romans do.
- wruza 4y ago
  I’m a Roman and have no clue what these AppData/Romaning are for. Dotfiles that I’m aware of are my files and I expect them to reside in my ~ atrium.
- klibertp 4y ago
  > When in Rome, do as the Romans do. Yeah, but then again, when you visit Rome for a short vacation as a tourist, the English versions of menus and such help, no? Just saying, some degree of consideration for non-natives is a good thing, as it will help the tourism business generate more revenue. Same for OSes: give me at least an option of staying with my old habits until I get used to the new ones, then there's a higher chance I'll switch.
codedokode 4y ago
> I prefer the app placing the config in the same place on every system. That is impossible because in Linux there is no drive letters and you cannot have the same path to a file as in Windows.

matheusmoreira 4y ago

I don't find it egregious at all. Nobody should go out of their way to integrate with Windows APIs when files work just fine everywhere.

Spivak 4y ago
It’s basically the same as looking up $XDG_CONFIG_HOME on GNU/Linux.
- matheusmoreira 4y ago
  That's just an environment variable while this ShGetKnownFolderPath thing is a Win32 API function. People should avoid directly depending on that stuff as much as possible. People aren't obligated to "comply" with the XDG specification either. It's not a bug to just use $HOME.
  - pie_flavor 4y ago
    You're directly depending on platform-specific stuff the moment you look up the user directory, because it's not $HOME on Windows either. There is a difference between being cross-platform, and being Linux but mangling it so it technically works on other platforms.
    - matheusmoreira 4y ago
      It's just a different variable: USERPROFILE. https://stackoverflow.com/a/42700844/512904 https://stackoverflow.com/a/42700844/512904 > being Linux but mangling it so it technically works on other platforms Sounds like the easiest way to solve this problem. I don't blame or shame developers for choosing it. This is simple and works everywhere: char * home = getenv("USERPROFILE"); if (home) { // Use home directory } The answer demonstrating the Windows API way has the following code to accomplish the same thing: WCHAR profilePath[MAX_PATH]; HRESULT result = SHGetFolderPathW(NULL, CSIDL_PROFILE, NULL, 0, profilePath); if (SUCCEEDED(result)) { // Use home directory } Yeah, I seriously doubt open source developers want to deal with this Windows bullshit. I sure don't. Maybe if you're getting paid.

codedokode 4y ago

I think "hidden" files are a bad idea. What's the point of hiding some of the files in a directory from user? It only makes things more confusing. For example the folder might look empty but in fact it could contain thousands of hidden files. You want to delete it as it is empty but accidentally delete important system files. Even worse, imagine if all files on an USB drive are marked as hidden. You see that the drive is empty but when you attempt to copy something to it see a message that there is no free space. One more example. Imagine if you have a project and want to edit an .env file. But as dotfiles are hidden in Linux you don't see this file and cannot open it. It turns out that Windows Explorer which doesn't hide dotfiles is much better for developing projects with Docker! There should be no hidden files. We cannot do anything with Windows and their MS-DOS legacy but Linux could stop hiding dotfiles in GUI and CLI commands.

8n4vidtmkvmk 4y ago
i just always list dotfiles for years now.. and my IDEs too. mostly a non issue.
- codedokode 4y ago
  And I have to enable showing them on every system I work with (and add -a to every ls command, and google which option enables incldues them in pattern expansion). That is annoying.
  - 8n4vidtmkvmk 4y ago
    Well.. ya. I set up my aliases and then forget about it again. Globbing is mildly annoying but i think there's a dotglob option or something you can set
klodolph 4y ago
Hidden files on MacOS were used sparingly—the main instance of a hidden file is the file which stores an icon for a folder, if the folder has a custom icon. Hidden files are only hidden from the UI, they appear normally in the command line. The standard Unix folders (usr, var, etc) are also hidden—to be honest, this is a compromise because the Unix filesystem hierarchy sucks, but we are saddled with it for backwards compatibility reasons. I did appreciate the relative clarity of old macOS systems—everything in the OS was in “System Folder”, the rest of the filesystem was yours, and you could freely move applications without breaking anything, uninstall them by putting them in the trash, etc.

rozab 4y ago

Windows is a lost cause anyway. Even Microsoft products (at a glance: IISExpress, Visual Studio, RDP, Powershell) happily dump their cruft in the Documents folder. I don't know where they imagine users should actually save the files they control.