Amahi Forums

Hello,

I noticed that if I copy files to a share on my Amahi server the file creation date/time isn't preserved, the copy takes the date/time of the moment the copy took place. After Greyhole does it's 'thing' the file time is changed again to 1 or 2 minutes after the copy time.

This is quite annoying for a couple of reasons:

1 - I care for the original file creation date for things like CAD files or source code files.
2 - If you use a file synchronization utility to sync a directory on a remote computer to a directory on your Amahi server (which I do), this creates chaos, because you can keep 'syncing' until your left mouse button wears out: every time Greyhole changes the file(date) after a short time the util thinks the files have changed.

This has probably something to do with Greyhole (and not Samba) because if I create a share on my Amahi server and don't include it in the pool, the file creation date seems to remain intact (and, of course, I don't get the 1/2 minutes timeshift).

Richard

Not all copy tools will copy the creating and last modified timestamps.
For example, the command line on Linux or Mac will not copy it (so you'll get a ctime and mtime = now when copying any file).
But the Mac Finder (and I'd guess the Windows Explorer) do copy those attributes.

Secondly, GH doesn't work twice on a specific file, unless it's been written to twice.
When you copy a file to a share, you only work with Samba. Once the file is complete on the share, then Samba logs the file operation to a log, that Greyhole will parse in the next 10 seconds. When that happens, then GH will process that file write, and do it's thing. This can happen in less than a second, or it can take much more time to happen, depending on how much work GH has queued.

Finally, it seems the fix for this is pretty trivial; since I using rsync to make file copies, we just need to add the -t option to keep timestamps.
If you'd like to try this, edit /usr/bin/greyhole in a text editor; look for the 3 instances of "rsync " and change them into "rsync -t ".
Ref: http://code.google.com/p/greyhole/source/detail?r=298 (click the + next to "Modify" to see the changes I committed for this.)
Then: Then try again.

This fix will be included in Greyhole 0.7.6 and +.

Not all copy tools will copy the creating and last modified timestamps.

I know. It's not so simple as it looks. That's why (among other things) I created a HDA share that's NOT in the pool and worked on that with the same tools

Secondly, GH doesn't work twice on a specific file, unless it's been written to twice.
When you copy a file to a share, you only work with Samba. Once the file is complete on the share, then Samba logs the file operation to a log, that Greyhole will parse in the next 10 seconds. When that happens, then GH will process that file write, and do it's thing. This can happen in less than a second, or it can take much more time to happen, depending on how much work GH has queued.

I'm not sure anymore how I came to that conclusion. I know I was pretty sure .... . It probably has something to do with the 'state file' the sync utility uses, which records the state at the time of copy and when analyzing again, after Greyhole did it's work, it noticed a different filetime; during the testing this was usually 60..90 seconds.

Anyway:

Finally, it seems the fix for this is pretty trivial

Trivial is fine with me... . Complicated fixes always take a lot of time and testing and come with a risk of breaking something else....

Then try again.

I did and it seems to work fine now!. I'll test some more and if I arrive at a different conclusion I'll let you know... But for now I'm really happy with the fix. Appreciate it, hope you don't get intimidated to much now that your work seems the only hope for the HomeServer community after Microsoft ditched the DriveExtender technique....

This fix will be included in Greyhole 0.7.6 and +.

Huh, I'm using 06.28 ? or is that Amahi specific?


Thanks again,

Richard

0.7.5 or 0.7.6 should be pushed to Amahi users in the upcoming days.
If you get 0.7.5, you'll need to re-do the above fix manually one last time, since that update will undo it.