5 ms·

Then you have problems with file system portability like you get with permissions.

by Evidlo 4y ago

sophacles 4y ago
That sounds like a standards problem more than something wrong with the idea itself.
wongarsu 4y ago
Dotfiles aren't universal either: Windows doesn't hide dotfiles and instead uses a file attribute to mark hidden files. Whatever you do will have portability concerns.
- PeterWhittaker 4y ago
  I would never argue that is universal, but just confine myself to the UNIX/Linux world. Were we to argue for universality, we’d be lost within a sea of /, \, -, /, //, \\, drive prefixes, and a few other things. Within the UNIX/Linux world, though, it’s a remarkably useful and effective convention, implemented and respected with considerable consistency. (Windows hidden files really aren’t, not once one drops to a CLI, and even then, it depends on the CLI. I’m not offering that as a criticism, but more of a caution of how difficult it is to get something like this to work. Extended attributes and even basic permissions have their twists and difficulties, even within a platform or platform family, let alone cross platform.)
  - em-bee 4y ago
    the primary difficulty is to implement a mechanism to carry those attributes in the first place. that's a problem we already have. once that mechanism is there, we can add whatever attributes that we want. this should have been a concern from the beginning. instead of the hackish workaround of encoding attributes into the filename. they should never have been there. even file-type extensions should have been a separate field of some sort right from the start.
    - PeterWhittaker 4y ago
      Like they were in Mac OS back in the day, when files had resource forks and data forks? Or like magic numbers in UNIX/Linux? The whole extension thing was odd from the beginning. When I first used Windows, after years of UNIX, extensions puzzled me. On UNIX, they told ME something, the OS and apps didn’t need them (/etc/magic did the trick), but here they were on Windows being given semantic value. Ironically, now that I think about it, I found Windows extensions odd for the same reason that some find hiding dotfiles on UNIX/Linux odd. This makes me chuckle ruefully.
      - em-bee 4y ago
        like resource forks. yes. or extended attributes today. magic numbers are a crude, expensive, and not always working workaround to detect the type of a file based on the first bytes of a data-stream. and there are programs that refuse to load a file if it has an extension that is not supported, even if the content of the file would be just fine. (can't think of an example though, but i definitely remember getting irritated when that happened) what bothered me about extensions in unix is that they were sometimes arbitrary or wrong. especially on the web, where urls had arbitrary extensions that related to how the page was produced, and not the content that was served (which was almost always html. other extensions only matched for files to be downloaded, but you could never trust it, so in most cases it served no purpose)

Then you have problems with file system portability like you get with permissions.

by Evidlo 4y ago

Then you have problems with file system portability like you get with permissions.

sophacles 4y ago

That sounds like a standards problem more than something wrong with the idea itself.

wongarsu 4y ago

Dotfiles aren't universal either: Windows doesn't hide dotfiles and instead uses a file attribute to mark hidden files. Whatever you do will have portability concerns.

PeterWhittaker 4y ago
I would never argue that is universal, but just confine myself to the UNIX/Linux world. Were we to argue for universality, we’d be lost within a sea of /, \, -, /, //, \\, drive prefixes, and a few other things. Within the UNIX/Linux world, though, it’s a remarkably useful and effective convention, implemented and respected with considerable consistency. (Windows hidden files really aren’t, not once one drops to a CLI, and even then, it depends on the CLI. I’m not offering that as a criticism, but more of a caution of how difficult it is to get something like this to work. Extended attributes and even basic permissions have their twists and difficulties, even within a platform or platform family, let alone cross platform.)
- em-bee 4y ago
  the primary difficulty is to implement a mechanism to carry those attributes in the first place. that's a problem we already have. once that mechanism is there, we can add whatever attributes that we want. this should have been a concern from the beginning. instead of the hackish workaround of encoding attributes into the filename. they should never have been there. even file-type extensions should have been a separate field of some sort right from the start.
  - PeterWhittaker 4y ago
    Like they were in Mac OS back in the day, when files had resource forks and data forks? Or like magic numbers in UNIX/Linux? The whole extension thing was odd from the beginning. When I first used Windows, after years of UNIX, extensions puzzled me. On UNIX, they told ME something, the OS and apps didn’t need them (/etc/magic did the trick), but here they were on Windows being given semantic value. Ironically, now that I think about it, I found Windows extensions odd for the same reason that some find hiding dotfiles on UNIX/Linux odd. This makes me chuckle ruefully.
    - em-bee 4y ago
      like resource forks. yes. or extended attributes today. magic numbers are a crude, expensive, and not always working workaround to detect the type of a file based on the first bytes of a data-stream. and there are programs that refuse to load a file if it has an extension that is not supported, even if the content of the file would be just fine. (can't think of an example though, but i definitely remember getting irritated when that happened) what bothered me about extensions in unix is that they were sometimes arbitrary or wrong. especially on the web, where urls had arbitrary extensions that related to how the page was produced, and not the content that was served (which was almost always html. other extensions only matched for files to be downloaded, but you could never trust it, so in most cases it served no purpose)