3 ms·

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 meta

by 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

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.