Is it possible to set x-amz-meta-creation-time during copy?

Hello, I have a netapp storage grid, in order to use an ILM rule to purge old files I need to set x-amz-meta-creation-time. Is that possible or is there a similar flag I can set when doing the upload? I searched and can't find any info so far, I have 2000 TB of data (30 M files) that I need to move which will take a few months, need to figure out the best way to do this (can't edit each one in the S3 bucket). Rclone keeps the timestamps which is great, but the bucket properties ignore it, I can resort to a script that looks at the timestamps if there isn't an easier way that I'm missing.

Thank you,
Mark

https://docs.netapp.com/sgws-110/index.jsp?topic=%2Fcom.netapp.doc.sg-s3%2FGUID-0B54A113-91F3-46F4-836E-094C367806D9.html

I've not heard of x-amz-meta-creation-time as a standard bit of metadata - is that a netapp thing?

It looks to have pretty much the same format as the modtime header (though rclone writes fractional seconds too).

Do you need the x-amz-meta-creation-time to be constant or the same as the mod-time?

Can you use the X-Amz-Meta-Mtime: 1570872777.632294776 headers that rclone already sets somehow?

Where are the files being copied from? From a different S3 bucket?
'

Hi Nick, I think it's just a netapp thing, it's a bucket property that gives you 3 options for cleaning up old files, injest, last access, or user defined.

x-amz-meta-creation-time needs to be the same as the mod-time, we have existing data going back 13 months and need to roll off the oldest, but netapp is ignoring the timestamps and views them all as the day you moved them. They are being copied from Isilon NAS storage.

Here's the options the ILM gives you, can't believe it can't just look at the timestamp...

https://library.netapp.com/ecmdocs/ECMP12481618/html/GUID-0BDEF044-146A-448A-905D-2DDD816C5F20.html

I can maybe look into scripting something using X-Amz-Meta-Mtime if I can't figure out how to make the bucket do the work.

Thanks again,
Mark

The easiest thing might be to make a patch to rclone, something like this

https://beta.rclone.org/branch/v1.50.1-042-g423e90dc-fix-netapp-creation-time-beta/ (uploaded in 15-30 mins)

This is a tiny patch which just duplicates the modtime into the creation-time for uploads.

diff --git a/backend/s3/s3.go b/backend/s3/s3.go
index c49d9c9b7..327922ca2 100644
--- a/backend/s3/s3.go
+++ b/backend/s3/s3.go
@@ -2036,6 +2036,7 @@ func (o *Object) Update(ctx context.Context, in io.Reader, src fs.ObjectInfo, op
        metadata := map[string]*string{
                metaMtime: aws.String(swift.TimeToFloatString(modTime)),
        }
+       metadata["creation-time"] = metadata[metaMtime]
 
        // read the md5sum if available for non multpart and if
        // disable checksum isn't present.

I'm not sure I want to merge that as-is as it is a bit special purpose, but see if it works for you!

It might be that it doesn't as the time rclone writes is a floating point number - that is easy to fix though.

Thanks! I tried it and see the creation time set for my October file, just have to wait and see if netapp plays nice:o) We have a test bucket set to 2 days so I'll know whenever it runs it's policy.

2019/11/14 10:42:07 DEBUG : HTTP RESPONSE (req 0xc00028e300)
2019/11/14 10:42:07 DEBUG : HTTP/1.1 200 OK
Content-Length: 740460
Accept-Ranges: bytes
Connection: KEEP-ALIVE
Content-Type: text/plain; charset=utf-8
Date: Thu, 14 Nov 2019 15:42:07 GMT
Etag: "3a772011d9f69adc07a1f18296c001f0"
Last-Modified: Thu, 14 Nov 2019 15:40:59 GMT
Server: StorageGRID/11.1.1.1
X-Amz-Meta-Creation-Time: 1571325874.1317375
X-Amz-Meta-Mtime: 1571325874.1317375
X-Amz-Request-Id: 970436793
X-Amz-Server-Side-Encryption: AES256

Hi Nick, one favor please... can you nix the floating point number part of it for me? The purge policy didn't work last night, the file attribute is exactly what the doc calls for minus the precision.

Thank you so much,
Mark

OK try this!

https://beta.rclone.org/branch/v1.50.1-047-gec09127b-fix-netapp-creation-time-beta/ (uploaded in 15-30 mins)

Thank you! Looks perfect, I owe you a pizza or something :o)

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2019/11/15 11:27:43 DEBUG : HTTP RESPONSE (req 0xc000137b00)
2019/11/15 11:27:43 DEBUG : HTTP/1.1 200 OK
Content-Length: 740460
Accept-Ranges: bytes
Connection: KEEP-ALIVE
Content-Type: text/plain; charset=utf-8
Date: Fri, 15 Nov 2019 16:27:43 GMT
Etag: "3a772011d9f69adc07a1f18296c001f0"
Last-Modified: Fri, 15 Nov 2019 16:27:30 GMT
Server: StorageGRID/11.1.1.1
X-Amz-Meta-Creation-Time: 1571325874
X-Amz-Meta-Mtime: 1571325874.1317375
X-Amz-Request-Id: 3315046852
X-Amz-Server-Side-Encryption: AES256

:smile:

well, see if it works and I'll consider whether I want to merge it (with a flag to enable).

Hi Nick, I can't imagine anyone would code their system to be case sensitive, but have you ever heard of anyone having an issue with camel case for the keys? All the netapp docs have lowercase for everything, I still am not seeing it delete as expected. Is it possible to make the keys all lowercase?

"To record the object creation time, so that you can use the User Defined Creation Time option for the reference time in an ILM rule, you need to store the value in a user-defined header named x-amz-meta-creation-time. For example: x-amz-meta-creation-time=1443399726."

Thanks so much,
Mark

I don't really have control over the case of the headers that - it is done by the AWS SDK.

If I use the s3cmd to read metadata from an object this is what I see. Does that work on objects that rclone uploaded?

$ s3cmd info s3://rclone/hello.txt
s3://rclone/hello.txt (object):
   File size: 6
   Last mod:  Fri, 20 Sep 2019 10:20:30 GMT
   MIME type: text/plain; charset=utf-8
   Storage:   STANDARD
   MD5 sum:   b1946ac92492d2347c6235b4d2611184
   SSE:       none
   Policy:    none
   CORS:      none
   ACL:       9bfbcc151aa51bb58efadf24b52326da3471878f2768be4a93298ac1a7e7c469: FULL_CONTROL
   x-amz-meta-mtime: 1542920776

Hey Nick, I think i'm good here, the case doesn't matter, I can see the date in the bucket through an admin tool, I think we just don't have the bucket rule setup correctly yet. I'll let you know if this starts working, the admin guy isn't back for another week.

appreciate all the help!
have a great weekend.

1 Like

Hey Nick, quick update, this works perfect! Files are getting peeled off by the bucket property, no clunky scripting needed on my end.

Thanks for the help, this was a lifesaver.
-Mark

Great!

What do you think I should do with this patch? it is a one line patch...

I could

  1. enable it permanently
  2. enable it on an option, say --s3-set-creation-time
  3. not merge it

what do you think is the right thing to do?

I think --s3-set-creation-time would be great, I'm sure somewhere out there someone has done this the hard way, I know I almost did :o)

That is easy enough...

Can you help me with the help text? Here is a start - please amend for accuracy!

The first line is the help when you do rclone help flags - the complete text is what you see in the docs

--s3-set-creation-time

Set x-amz-creation-time for use with netapp storage grid

If set this flag will set x-amz-creation-time metadata when uploading objects. This will be set to the modified time of the uploaded object in seconds since the epoch.

This flag is understood by netapp storage grid and can be used to XXX?

Thanks

hey Nick, sorry, just noticed this post. I can try to explain a bit with an example: Thanks for the help, this works perfect!

This flag is understood by netapp storage grid and can be used to purge files based on this time vs. the injestion time (the time they were actually moved to S3). When migrating old files to S3 they all appear "new" and a policy based on injestion time to delete files older than say 365 days would never delete files that are actually older than 365 days.

From the netapp manual:
"To record the object creation time, so that you can use the User Defined Creation Time option for the reference time in an ILM rule, you need to store the value in a user-defined header named x-amz-meta-creation-time. For example: x-amz-meta-creation-time=1443399726."

Thanks for that! Will try to find time to finish this in the next couple of days!

Thanks for this, i'm moving millions of files, this helps more than you can imagine!