Hi Kyol,

Please find the below mentioned document,it might help:

https://support.emc.com/docu31540_Using-VNX-File-Level-Retention-7.0.pdf?language=en_US

Thanks

Jyothi

Thanks for the hint,

but I can not find the mistake I have made.
FLR Monitor is running and locking the files as soon as they are copied on to the share.

I tested more and found out that when I set the retention to 20 Years the "Date Accessed" ist shown correct, 2036.

But when I set it to more the 24 Years the Date becomes 1978. So it looks like the date was set to infinite for some reason.

What am I doing wrong?

this really smells like a problem with the Unix 32 bit date ending in 2038

Support for Retention Dates beyond 2038 was added in VNX OE 7.1

what versions of VNX OE and the FLR toolkit are you using?

my advice:

check what your epoch date is set to - see nas_fs

maybe your fs was created with an older VNX OE Version like 7.0 ?

could be problem with FLR monitor in setting the date or just in displaying it

check the FLR log on the file system itself - it is authorative

P.S.:

Instead of the manual linked above please use the latest VNX OE Manual Jyothi quoted is from an old version that doesnt support retention beyond 2038

Hi,

I'm using latest FLR Monitor 4.1.1.25 on Windows 2012R2

NAS Version 8.1.3-79

Epoch Year is set to 2003

I have changed the Epoch Year to 2016 and also to 2037 but the Date ist still 1978, so I changed it back to 2003

When i check the Files with #ls -l --time-style=full-iso --time=atime

-r--r--r-- 1 32768 32771 6 1978-04-04 11:40:28.000000000 +0100 test - Copy (10).txt

-r--r--r-- 1 32768 32771 6 1978-04-04 11:40:28.000000000 +0100 test - Copy (11).txt

-r--r--r-- 1 32768 32771 6 1978-04-04 11:40:28.000000000 +0100 test - Copy (12).txt

-r--r--r-- 1 32768 32771 6 1978-04-04 11:40:28.000000000 +0100 test - Copy (13).txt

the Date is not correct

FLR Log states the following: (I have also listed the Inode Number)

#cat ../FLR_Logs/flrLog20160404110852

Mon Apr  4 09:23:27 2016 : Worm commit clean file : Inode No = 131 : Generation No = 1477714446 : Uid = 0 : Gid = 1 : FileMode = 444 : FileSize = 6 : RP = Wed Apr  4 09:23:28 2046 : Passed

Mon Apr  4 09:23:27 2016 : Delete worm committed file : Inode No = 131 : Generation No = 1477714446 : Uid = 32768 : Gid = 32768 : FileMode = 444 : FileSize = 6 : RP = Wed Apr  4 09:23:28 2046 : Failed

Mon Apr  4 09:27:22 2016 : Delete worm committed file : Inode No = 131 : Generation No = 1477714446 : Uid = 32768 : Gid = 32768 : FileMode = 444 : FileSize = 6 : RP = Wed Apr  4 09:23:28 2046 : Failed

[root@vnx521 New folder9]# ls -il --time-style=full-iso --time=atime

131 -r--r--r-- 1 32768 32771 6 1978-04-04 11:40:28.000000000 +0100 test - Copy (10).txt

the fact that an ls will show an "incorrect" value is normal and is because the date store inside the file system is still 32 bit - just interpreted with the epoch as an offset for FLR purposes.

If you want to see the effective FLR date you need to use the FLR Tools or look at the log

The FLR log is what is authoritive.

Also - be aware of what changing the epoch on existing locked files does.

I know it's an old thread, i am trying to simulate a copy from VNX FLR (E) FS and i am facing a similar issue. Whenever i copy the file, it doesn't maintain the expected retention as it is not even updated properly in the source file.Do we have any solution for this ?