4 ms·

Its hostile for power users but it prevents grandpa from renaming 'IMG_144.jpg' to 'Idaho_grandkids', hammering enter on the 'are you sure you want this' nag sc

by jorvi 7y ago

Its hostile for power users but it prevents grandpa from renaming 'IMG_144.jpg' to 'Idaho_grandkids', hammering enter on the 'are you sure you want this' nag screen and then wondering what broke his picture.

ken 7y ago
On Macs before 2001, that used to work! We didn't used to cram pieces of file metadata into file names. File type was stored its own slot. The hidden-ness of a file was stored in its own slot. I find it amazing that despite the industry's trend in recent years away from string-typing and towards static-typing, metadata-in-file-name just won't die. I'm all for removing old ways of doing things that were bad, when we have a better way to do them. What we have here, with type-in-extension (and visibility-in-prefix), is a legacy system for which there is so far no workable substitute (on any system, much less all systems). A person can't be fully computer literate and not know what extensions are. UTI has some nice features, but it's still based on extensions (which are keys into the database with the information you really want). This weird halfway point, where every user has to be a "power user" of the filesystem in order to not break their own files, will live on until either types are made primary again, or until we're all reduced to using standalone "apps" with app-specific storage and we can't share any data except as the app author decided to allow.
- dreamcompiler 7y ago
  Apple used to be the innovator in file metadata. They stopped when Steve came back because proper metadata made it more difficult to share files with Windows and Unix. And we're still stuck with crap metadata to this day.
  - munk-a 7y ago
    Given the implementations I've seen of file metadata outside of the extension I'm okay with this - every time OSes (especially windows) tries to strip away the extension it ends up switching the file type from being a description of "what am I" to "what can open me", I really dislike "what can open me" especially when we get into a lot of common office work file formats. Knowing the difference between .rtf, .txt, .doc and .docx is important because of the special attributes of those files - additionally I frequently run into issues with character encoding and that should be an even easier problem to solve so... my outlook is not very optimistic.
    - dreamcompiler 7y ago
      Agreed. Apple's pre-OSX metadata system was two pieces: "What am I" and "Who created me." This was an amazingly flexible system that just worked and was the best of both worlds.
      - TylerE 7y ago
        I seem to remember a whole ecosystem of shareware apps To change/fix that metadata.
      - NikkiA 7y ago
        @TylerE That's fine, not every task that is possible must be directly supported by the OS - third party apps to fiddle with data that is considered non-primary workflow like that is OK.
astrobe_ 7y ago
It's not the picture that broke, it's not the user that is dumb, but the system that is broken. Dot extensions is a concept that should never have seen the light of the 21st century. Or at least it should be a last resort for the system to guess the file format for those formats that don't have magic numbers in their headers or for lesser known formats.
- cm2187 7y ago
  Or more generally the header should contain the metadata of the file: date modified, filetype, comments, icon, etc, rather than spreading that between the filesystem (with different filesystems having inconsistent dates), the OS, etc.
  - NikkiA 7y ago
    I disagree, locality data such as ownership, modified date, comments, permissions even, should not be part of the file, it breaks things like repeatable builds, version control and anything where the contents of the file are considered static. shadow files (._*) and directory clutter (.DS_Store/desktop.ini) are one solution, but they're ugly and frustrating, having separate areas in the filestore (like a resource fork, but designed to be ephemeral) are a much more sane solution.
    - cm2187 7y ago
      I don't think it breaks anything. If the world had gone this way, all the functions you use to read a file would read the data from the first byte after the header.
      - NikkiA 7y ago
        In that situation the metadata is no longer part of the 'file' then, and would be lost by a 3rd party copy function unless extra API functions are used to copy the metadata. At this point, it might as well be a "resource fork" or whatever you want to call your secondary file contents at the fs layer shrug
deleted 7y ago
[deleted]
e12e 7y ago
Does Mac still have resource forks? Either way, I'm sure it still has decent magic number decoding. Who (except family members in windows?) would care about the missing extensions? The only real reason i care is for vim file detection (in Linux). How sad is that? :'(
- dreamcompiler 7y ago
  Resource forks are still supported. At least they were with HFS+. They might be gone in APFS. In any case with each release Apple makes it harder to access them.
  - ksherlock 7y ago
    APFS still supports resource forks. (They're not as baked-in as HFS/HFS+, though.) APFS has good extended attribute support. Whereas linux extended attributes might be limited to 64k, APFS extended attributes can be significantly bigger (I just created a 32MB one). The xnu kernel has some ugly hacks (pre-dating APFS) which make the "com.apple.ResourceFork" available as a file ("/..namedfork/rsrc"). On HFS/HFS+, file/..namedfork/rsrc will always exist (and usually be empty). on APFS, file/..namedfork/rsrc will generate an ENOENT error if the resource fork/attribute doesn't exist.
- NikkiA 7y ago
  Even NTFS supports resource forks, noone uses it for anything though.
yrro 7y ago
This was never a problem with classic Mac OS. Files had a type code and a creator code. The type code told application whether they could open the file. The creator code told the Finder which application to open when the file was double-clicked. It was impossible for the user to change either (in the stock OS).
- munk-a 7y ago
  Wait a tic - so the creator code forced the opening program to always be the same for a given file? There way no way to declare a preference that `.csv` files should now be opened with textedit or some such?
  - yrro 7y ago
    Not as far as I remember, though I don't have an old Mac handy to check. Anyone? :)
- thaumasiotes 7y ago
  > It was impossible for the user to change either (in the stock OS). That's... much, much worse than dot extensions.
  - mrkstu 7y ago
    He's mis-stating it slightly. You couldn't fiddle with a file's creator code, but there wasn't much reason to. The type codes were editable, in the sense you could choose the default app you wanted to open files of that type, which is really what you'd want to modify most of the time.
    - yrro 7y ago
      I don't remember this being the case. I don't think it was possible to change either a file's type or creator code without a tool such as ResEdit that wasn't included in the OS. BTW, I think you're referring to the 'creator' code, not the 'type' code. The 'creator' code determined which application would open a file when it was opened. And it was per-file; I don't remember any mention of a system-wide 'default application' or anything like that. This was actually rather nice in practice. It meant a JPEG image created by e.g., GraphicsConverter would be opened by GraphicsConverter when double-clicked; whereas one saved by a web browser would be opened in the web browser. But either could be dragged into either application in order to open the web-browser-saved image with GraphicsConverter.
im3w1l 7y ago
I like the design principle "it should be easy to do easy things and possible to do hard things". Showing the extension, but requiring terminal use to change it would a decent compromise.
nyuszika7h 7y ago
That wouldn't really be a problem most of the time, since Windows Vista only the actual filename is part selected by default when renaming a file.

by jorvi 7y ago

ken 7y ago

On Macs before 2001, that used to work! We didn't used to cram pieces of file metadata into file names. File type was stored its own slot. The hidden-ness of a file was stored in its own slot. I find it amazing that despite the industry's trend in recent years away from string-typing and towards static-typing, metadata-in-file-name just won't die. I'm all for removing old ways of doing things that were bad, when we have a better way to do them. What we have here, with type-in-extension (and visibility-in-prefix), is a legacy system for which there is so far no workable substitute (on any system, much less all systems). A person can't be fully computer literate and not know what extensions are. UTI has some nice features, but it's still based on extensions (which are keys into the database with the information you really want). This weird halfway point, where every user has to be a "power user" of the filesystem in order to not break their own files, will live on until either types are made primary again, or until we're all reduced to using standalone "apps" with app-specific storage and we can't share any data except as the app author decided to allow.

dreamcompiler 7y ago
Apple used to be the innovator in file metadata. They stopped when Steve came back because proper metadata made it more difficult to share files with Windows and Unix. And we're still stuck with crap metadata to this day.
- munk-a 7y ago
  Given the implementations I've seen of file metadata outside of the extension I'm okay with this - every time OSes (especially windows) tries to strip away the extension it ends up switching the file type from being a description of "what am I" to "what can open me", I really dislike "what can open me" especially when we get into a lot of common office work file formats. Knowing the difference between .rtf, .txt, .doc and .docx is important because of the special attributes of those files - additionally I frequently run into issues with character encoding and that should be an even easier problem to solve so... my outlook is not very optimistic.
  - dreamcompiler 7y ago
    Agreed. Apple's pre-OSX metadata system was two pieces: "What am I" and "Who created me." This was an amazingly flexible system that just worked and was the best of both worlds.
    - TylerE 7y ago
      I seem to remember a whole ecosystem of shareware apps To change/fix that metadata.
    - NikkiA 7y ago
      @TylerE That's fine, not every task that is possible must be directly supported by the OS - third party apps to fiddle with data that is considered non-primary workflow like that is OK.

astrobe_ 7y ago

It's not the picture that broke, it's not the user that is dumb, but the system that is broken. Dot extensions is a concept that should never have seen the light of the 21st century. Or at least it should be a last resort for the system to guess the file format for those formats that don't have magic numbers in their headers or for lesser known formats.

cm2187 7y ago
Or more generally the header should contain the metadata of the file: date modified, filetype, comments, icon, etc, rather than spreading that between the filesystem (with different filesystems having inconsistent dates), the OS, etc.
- NikkiA 7y ago
  I disagree, locality data such as ownership, modified date, comments, permissions even, should not be part of the file, it breaks things like repeatable builds, version control and anything where the contents of the file are considered static. shadow files (._*) and directory clutter (.DS_Store/desktop.ini) are one solution, but they're ugly and frustrating, having separate areas in the filestore (like a resource fork, but designed to be ephemeral) are a much more sane solution.
  - cm2187 7y ago
    I don't think it breaks anything. If the world had gone this way, all the functions you use to read a file would read the data from the first byte after the header.
    - NikkiA 7y ago
      In that situation the metadata is no longer part of the 'file' then, and would be lost by a 3rd party copy function unless extra API functions are used to copy the metadata. At this point, it might as well be a "resource fork" or whatever you want to call your secondary file contents at the fs layer shrug

deleted 7y ago

[deleted]

e12e 7y ago

Does Mac still have resource forks? Either way, I'm sure it still has decent magic number decoding. Who (except family members in windows?) would care about the missing extensions? The only real reason i care is for vim file detection (in Linux). How sad is that? :'(

dreamcompiler 7y ago
Resource forks are still supported. At least they were with HFS+. They might be gone in APFS. In any case with each release Apple makes it harder to access them.
- ksherlock 7y ago
  APFS still supports resource forks. (They're not as baked-in as HFS/HFS+, though.) APFS has good extended attribute support. Whereas linux extended attributes might be limited to 64k, APFS extended attributes can be significantly bigger (I just created a 32MB one). The xnu kernel has some ugly hacks (pre-dating APFS) which make the "com.apple.ResourceFork" available as a file ("/..namedfork/rsrc"). On HFS/HFS+, file/..namedfork/rsrc will always exist (and usually be empty). on APFS, file/..namedfork/rsrc will generate an ENOENT error if the resource fork/attribute doesn't exist.
NikkiA 7y ago
Even NTFS supports resource forks, noone uses it for anything though.

yrro 7y ago

This was never a problem with classic Mac OS. Files had a type code and a creator code. The type code told application whether they could open the file. The creator code told the Finder which application to open when the file was double-clicked. It was impossible for the user to change either (in the stock OS).

munk-a 7y ago
Wait a tic - so the creator code forced the opening program to always be the same for a given file? There way no way to declare a preference that `.csv` files should now be opened with textedit or some such?
- yrro 7y ago
  Not as far as I remember, though I don't have an old Mac handy to check. Anyone? :)
thaumasiotes 7y ago
> It was impossible for the user to change either (in the stock OS). That's... much, much worse than dot extensions.
- mrkstu 7y ago
  He's mis-stating it slightly. You couldn't fiddle with a file's creator code, but there wasn't much reason to. The type codes were editable, in the sense you could choose the default app you wanted to open files of that type, which is really what you'd want to modify most of the time.
  - yrro 7y ago
    I don't remember this being the case. I don't think it was possible to change either a file's type or creator code without a tool such as ResEdit that wasn't included in the OS. BTW, I think you're referring to the 'creator' code, not the 'type' code. The 'creator' code determined which application would open a file when it was opened. And it was per-file; I don't remember any mention of a system-wide 'default application' or anything like that. This was actually rather nice in practice. It meant a JPEG image created by e.g., GraphicsConverter would be opened by GraphicsConverter when double-clicked; whereas one saved by a web browser would be opened in the web browser. But either could be dragged into either application in order to open the web-browser-saved image with GraphicsConverter.

im3w1l 7y ago

I like the design principle "it should be easy to do easy things and possible to do hard things". Showing the extension, but requiring terminal use to change it would a decent compromise.

nyuszika7h 7y ago

That wouldn't really be a problem most of the time, since Windows Vista only the actual filename is part selected by default when renaming a file.