Please describe the problem.
I see that files are synced between my computers with git-annex but the timestamps do not match. The one that receives files always puts the current time of file creation on the file.
What steps will reproduce the problem?
Install git-annex on two computers. Connect with XMPP. Then add cloud storage with shared encryption for transferring files. Since you want also backup, choose "full backup" as the type of cloud storage.
What version of git-annex are you using? On what operating system?
Downloaded binary package dated 13/09/2014 amd64 Ubuntu 14.04.
Please provide any additional information below.
Files are in sync. For example, I move a file from a directory to my synced annex directory. It contains timestamp of 01/01/2010 for example. Once the file gets transferred to the remote computer, it gets current time, for example 20/09/2014 rather than keeping 01/01/2010.
All computers are linux based, ext4 filesystems. File transfers are done through shared encryption rsync remote.
Thanks Joey for the comment.
But when syncing two repos, timestamps are critical at least for my use case. I can't lose this info. Even if it's expensive.
Appreciate if you can consider to add it for direct mode repos, ie when a file is synced to another repo and created there, it shall carry at least the mtime of the file in source repo. Owncloud sync does it, btsync does it, although I know git-annex is different than those.
You can try to store the timestamps just before commit and restore them on checkout.
Have a look at metastore: it is a ready-made solution for plain git. Maybe you can adapt it to git-annex.
Isn't this what the metadata feature does though? http://git-annex.branchable.com/design/metadata/
With annex.genmetadata true set, it should store year and mont (but not day/time? if so why not?
Is the missing piece of the puzzle to apply the metadata again on checkout?
I confirm this issue is still present in the debian testing version 5.20150731. This really makes git-annex quite unusable for me, as part of my setup is that my server downloads various podcasts (think news videos from euronews, german tagesschau, some youtube podcasts), which then get distributed to my other computers. This way I don't have to use youtube etc., which makes a huge difference in terms of speed (my main home computer is from 2006 and it plays all hte videos just fine, but a website likie youtube.com is too much for it). At a speed of single shortcut I see a list of newest podcasts and I can choose one without bothering to open the webbrowser.
The point is that I really like to have all those podcasts to be sorted by their modified date, for rather obvious reasons. (with dropbox it works fine.)
--templateflag and prefix the filename with the date. See downloading podcasts. If you need very accurate modification times that won't work but should work in this case?I've created a number of timestamp-related bugs that will hopefully result in better timestamp support:
There are two conflicting approaches to mtimes:
Treat them as local artifacts
This works great with Make, and generally with any software that works on "is newer than" properties.
Treat them as preservation-worthy file attributes
This is generally required by tools that compare time stamps by identity.
Both approaches break tools that expect the other, and no single out-of-the-box choice will make all users happy. Tools like metastore, a bespoke solution like etckeeper's generated mkdir/chmod file or a git-annex solution like storing the full mtime at genmetadata time with a (local or repository-wide) option to set the mtime at annex-get time would be convenient.
One more application where this would be relevant is sharing generated thumbnails among clones of repositories (to eventually maybe even have them available when the full files are not present) following the XDG specification on shared thumnail repositories. Not only does that design rely on the mtimes of the thumbnail and the file to match, it even encodes the mtime again inside the thumbnail, practically requiring all checkouts to not only have consistent mtimes between thumbnails and files, but identical ones.
Note that
git-annex adddoes preserve the timestamp of the file while adding it to the annex. Much the same as a file's timestamp is the same aftergit addas it was before running that command. Whengit-annex addreplaces a file with a symlink, it even makes the symlink's timestamp be the same as the original file.What git-annex does not do is try to store the timestamp in git and arrange for clones that receive the file to get the same timestamp. There are lots of things like this that someone might want git to preserve, but git doesn't, and it's out of scope for git-annex to try to work around git's limitations in these areas. Plenty of room for other tools that add git tracked timestamps, etc. Many such tools exist.