Is it possible for IPFS to return the timestamp or datetime of a file’s addition?
The same for “ipfs name publish”.
Basically, ipfs keeps time of an action or not?
I need this for synchronization.
File addition is relative to the node. I’m not sure your node tracks when it adds a block.
Yes you’d likely have to log this on your own.
I’m not sure on this one.
Generally speaking, it doesn’t. IPFS is more interested in the content itself instead of when that content was seen.
Seems like something you’ll have to track / maintain / solve yourself, at least for the time being. I’m not sure I see how IPFS as a protocol could assist here
1 Like
It’s not the addition time but there is an open bounty for adding mtime (as well as mode) that is really close to being done. When that’s done you could use that in a limited way by updating the modification time right before adding the file.
opened 07:03PM - 21 Feb 20 UTC
bounty
epic
kind/enhancement
## This issue has a bounty!
Successfully closing this issue by producing a prod… uction-ready, mergeable PR can earn you not only the undying love of the IPFS community — it can net you a financial reward. [See the current list of bounty issues and their values here.](https://github.com/ipfs/devgrants/projects/1)
## The need in brief
Add UnisFSv1.5 metadata support per the spec https://github.com/ipfs/specs/blob/master/UNIXFS.md#data-format, which includes: specifying metadata, respecting existing metadata, and displaying metadata.
This aims to support large data import use cases (ex package managers), who need to retain file metadata, particularly last modified time (`mtime`), in order to selectively sync only data that has changed. Up until now if you wanted to host a large data set on IPFS, like a package manager's repository, it would be difficult to update - but with file `mtime` you can only reimport the changed files, making things much more efficient.
## Deliverable
* Implement the new mode & mtime fields and obey the new rules around default modes & mtimes as per the [metadata spec](https://github.com/ipfs/specs/blob/master/UNIXFS.md#metadata).
* Plumb this metadata all the way through from `ipfs add` on one IPFS node to `ipfs get` on another.
* An end-to-end [sharness](https://github.com/ipfs/go-ipfs/tree/master/test/sharness) test that validates that this metadata is preserved.
## Requirements
* This feature must be interoperable with js-ipfs's implementation of the UnixFSv1.5 spec.
* The behavior of `ipfs add` must not change except when the user has requested that metadata be preserved via the appropriate flags (see the implementation details below). Specifically, the final hash produced by `ipfs add` must not change.
* The final hash of files added with this feature enabled must match the hash produced by javascript.
## Guidelines
- Please use the [IPFS Go Contributing Guidelines](https://github.com/ipfs/community/blob/master/CONTRIBUTING_GO.md) as your north star — **adherence to these guidelines are crucial when it comes to awarding a potential bounty**!
- Please DO NOT bundle a general code refactor with the completion of this bounty!
2 Likes
