unstable modtimes

[knupfer]

Version/Platform/Processor information (from ipfs version --all):

go-ipfs version: 0.4.3-dev-b5fbc01
Repo version: 4
System version: amd64/linux
Golang version: go1.6.2

Type (bug, feature, meta, test failure, question):

bug

Area (api, commands, daemon, fuse, etc):

commands

Priority (from P0: functioning, to P4: operations on fire):

Description:

ipfs get and ipfs get --archive produce files with touched modtime.
It would be more sensible to set these uniformly to unix time 0 (1.1.1970).
This would avoid receiving tarballs with unstable hashes and reflect better the immutability.

[jbenet]

Not 100% sure modtime is put into unixfs atm.

What does git do in this regard?

[knupfer]

git does the same, it doesn't save modtimes, but the files in the working tree aren't immutable.

[jbenet]

I'm not sure that

It would be more sensible to set these uniformly to unix time 0 (1.1.1970).

makes sense. it may have weird bad edge cases. can we think of any?

ipfs get and ipfs get --archive produce files with touched modtime.
git does the same, it doesn't save modtimes, but the files in the working tree aren't immutable.

Well, when you ipfs get, it's like a git clone or git checkout, so you sort of get stuff dumped into a "working directory".

I hear you though, i want to make it nicer/easier. Let's just keep discussing options and pros/cons

[knupfer]

• On nixos, they set the stuff in their store to unix time 0 without problems as far as I know
• A program which depends on the modtime would produce at the moment indeterminate results, even though the paths are deterministic
• Touching the files doesn't give any additional information and in fact isn't correct, because the files aren't modified
• Producing unstable tarballs makes it impossible to verify the integrity of a downloaded tarball from the public gateway and deduping on file basis by requesting to pack a dir into a tarball via the api.
• An other possibility would be to store modtimes as well in ipfs, but I rather dislike this option

[jbenet]

Agreed, let's do what git and nixos do?
On Tue, Aug 30, 2016 at 11:39 PM quxbar notifications@github.com wrote:

• On nixos, they set the stuff in their store to unix time 0 without
  problems as far as I know
• A program which depends on the modtime would produce at the moment
  indeterminate results, even though the paths are deterministic
• Touching the files doesn't give any additional information and in
  fact isn't correct, because the files aren't modified
• Producing unstable tarballs makes it impossible to verify the
  integrity of a downloaded tarball from the public gateway and deduping on
  file basis by requesting to pack a dir into a tarball via the api.
• An other possibility would be to store modtimes as well in ipfs, but
  I rather dislike this option

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#3139 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAIcoUsEC4a0XB2OHFIpcW_MnN-a7_a_ks5qlE6_gaJpZM4JvIPi
.

[kevina]

Not sure what is being agreed to here. But for the record I would be against ipfs get setting the modtime to unix time 0 by default.

[whyrusleeping]

@kevina what issues do you have with setting the modtime to 0?

[kevina]

@whyrusleeping this is an old issue but setting the modtime of files on disk after retrieving it with ipfs get to a useless value of "1970-01-01 00:00:00 UTC" seams like a really bad idea. If there is nothing sensible to set it to they should just leave the modtimes of the files alone like git does.

[achingbrain]

The metadata section of the spec has a section on applying metadata from a UnixFSv1.5 DAG to a non-IPFS target - it says that if the target requires an mtime value and no mtime value has been set in the DAG, that it should be set to 0/1970-01-01T00:00:00Z.

This is to prevent inconsistencies in metadata, similar to the nixos approach outlined above.

[Stebalien]

Will be fixed by #6920.