5 ms·

>No, just an explicitly-defined metadata field. Inference would be worse than filename extensions (which are awful). Which are bad because those don't survive

by gsich 3y ago

>No, just an explicitly-defined metadata field. Inference would be worse than filename extensions (which are awful). Which are bad because those don't survive filesystem transmissions. A filename with extension will.

veidr 3y ago
Right, that was the original point that I was trying to make (but botched). The 80s Mac solved this near-perfectly, but then regressed to the current "just add a dot and some gibberish to the filename (and perhaps, or perhaps not, hide the gibberish and dot). Because when you copy a file to some other system (e.g. USB drive, or email attachment, etc), only the common properties survive. So having a filesystem with awesome capabilities that the others lack becomes worse, not better. (T_T)
duped 3y ago
> Which are bad because those don't survive filesystem transmissions. A filename with extension will. It won't actually because paths are not portable across file systems. The big reason is case sensitivity (and yes, some file extensions are case sensitive), but there's also issues with ASCII vs UTF-8 vs UTF-16 encoding. Meanwhile there are multiple standards for exchanging file metadata between file systems (SMB, NFS, FUSE, FTP, whatever). Most of these support arbitrary metadata on files.
- gsich 3y ago
  A path is not a filename. The filename is part of it. Even with encoding issues, the chances that a filename survives are still much higher than filesystem metadata. For example: HTTP does not supply that metadata, so a file would lose it's "extension". Where would you store mimetype? Not in the file obviously.
  - duped 3y ago
    There's actually quite a bit of metadata that needs to be preserved when moving files between filesystems (file type, permissions, atime/ctime/mtime). Modern file systems support extended attributes for regular files and you can copy files between file systems with xattrs without too much trouble these days. In fact it's arguable that metadata is more reliable than file names, because that metadata is more standardized. > For example: HTTP does not supply that metadata, so a file would lose it's "extension". Where would you store mimetype? Not in the file obviously. Not sure what this point is. It's up to the HTTP serving application to determine what the mimetype of another file is however it needs to. A limited design could use file extensions, but a resilient design would just query the file system for unambiguous metadata. Like I said, there are multiple ways to do this. There's a lot of stuff that's not "in" the file. Like it's name.
    - gsich 3y ago
      >There's actually quite a bit of metadata that needs to be preserved when moving files between filesystems (file type, permissions, atime/ctime/mtime). Modern file systems support extended attributes for regular files and you can copy files between file systems with xattrs without too much trouble these days. Those are not hard requirements. It's nice to have, but in doubt it will just be what the destination filesystems think those values should be. >There's a lot of stuff that's not "in" the file. Like it's name. Correct. And everything not in the file is in danger of being lost. The filename (with extension) is the minimal viable data that has a chance to survive. The extension even more so than the basename.

by gsich 3y ago

veidr 3y ago

Right, that was the original point that I was trying to make (but botched). The 80s Mac solved this near-perfectly, but then regressed to the current "just add a dot and some gibberish to the filename (and perhaps, or perhaps not, hide the gibberish and dot). Because when you copy a file to some other system (e.g. USB drive, or email attachment, etc), only the common properties survive. So having a filesystem with awesome capabilities that the others lack becomes worse, not better. (T_T)

duped 3y ago

> Which are bad because those don't survive filesystem transmissions. A filename with extension will. It won't actually because paths are not portable across file systems. The big reason is case sensitivity (and yes, some file extensions are case sensitive), but there's also issues with ASCII vs UTF-8 vs UTF-16 encoding. Meanwhile there are multiple standards for exchanging file metadata between file systems (SMB, NFS, FUSE, FTP, whatever). Most of these support arbitrary metadata on files.

gsich 3y ago
A path is not a filename. The filename is part of it. Even with encoding issues, the chances that a filename survives are still much higher than filesystem metadata. For example: HTTP does not supply that metadata, so a file would lose it's "extension". Where would you store mimetype? Not in the file obviously.
- duped 3y ago
  There's actually quite a bit of metadata that needs to be preserved when moving files between filesystems (file type, permissions, atime/ctime/mtime). Modern file systems support extended attributes for regular files and you can copy files between file systems with xattrs without too much trouble these days. In fact it's arguable that metadata is more reliable than file names, because that metadata is more standardized. > For example: HTTP does not supply that metadata, so a file would lose it's "extension". Where would you store mimetype? Not in the file obviously. Not sure what this point is. It's up to the HTTP serving application to determine what the mimetype of another file is however it needs to. A limited design could use file extensions, but a resilient design would just query the file system for unambiguous metadata. Like I said, there are multiple ways to do this. There's a lot of stuff that's not "in" the file. Like it's name.
  - gsich 3y ago
    >There's actually quite a bit of metadata that needs to be preserved when moving files between filesystems (file type, permissions, atime/ctime/mtime). Modern file systems support extended attributes for regular files and you can copy files between file systems with xattrs without too much trouble these days. Those are not hard requirements. It's nice to have, but in doubt it will just be what the destination filesystems think those values should be. >There's a lot of stuff that's not "in" the file. Like it's name. Correct. And everything not in the file is in danger of being lost. The filename (with extension) is the minimal viable data that has a chance to survive. The extension even more so than the basename.