Metadata

[jbenet]

The unixfs datastructure has an object type called Metadata -- the goal was to put:

• unix attrs (permissions, etc)
• xattrs
• mime type

and more in there. it may be useful to discuss more relevant things here.

[eminence]

How was the metadata object going to be linked in?

Could the IPLD stuff replace the Metadata object type?

[jbenet]

@eminence definitely for some stuff, but we should still have a clear format for FS attrs.

[mguentner]

The FS in IPFS is currently not really usable as it lacks a few rather important flags and information. So in order to get it right next time nothing should be forgotten.

Here is a list of metadata attributes that modern filesystems are using with a short discussion whether it makes sense in IPFS. Please share your opinion :)

• Owner: Not in scope, owner is implicit through e.g. fuse

• POSIX Permissions: Partial. At least Execute and Write should be implemented.

  Explanation:

  • Execute: Whether the execute bit will be set when mounting through fuse
  • Write: Whether changes are allowed through fuse. It can be explicitly allowed, denied by setting chmod +w or chmod -w
• Creation/Modify Timestamp: Yes
• Metadata Timestamp: Maybe
• Access Control Lists: No
• MAC: No
• Checksums: No
• Extended Attributes: Maybe

[kalmi]

Optional modification timestamps are a must imo, and the question is: How should timestamps be stored? Is the precision(nanoseconds) and range(year 1678-2262) returned by UnixNano sufficient? Or if it's not, then for a really future (and past) proof solution the following structure could be used:

message timespec {
  optional int64 sec = 1; //since epoch
  optional uint32 nsec = 2;
}

I believe that modification times should be captured as precisely as the most precise filesystems do it (nanosecond-accuracy afaik).

[mib-kd743naq]

The reason I proposed the split secs / subsecs specification was because while sub-second resolution is possible on several filesystems, it is not prevalent. Thus it greatly simplifies random implementations to have a mandatory second portion and an optional subsecond portion. I.e. my proposal is:

message timespec {
  required uint64 sec = 1;    // I am not aware of negative epoch support in any library
  optional fixed32 nsec = 2;
}

[kalmi]

@mib-kd743naq I would consider sub-second resolutions prevalent:

• ext4 (with its default inode size) uses nanosecond resolution
• ntfs timestamps have 100 nanosecond (0.1 microsecond) resolution

[kalmi]

@mib-kd743naq golang's own time library has support for negative epoch times, and NTFS timestamps start at January 1, 1601 (UTC) [1].

I don't know why anyone would have files with timestamps like that, but I would want them to be able represent them in ipfs and restore them on filesystems that support it.

[1] https://support.microsoft.com/en-us/help/188768/info-working-with-the-filetime-structure