Hi,

I assume you are using FileMover not for its main purpose HSM but to to manage manage retention dates for VNX File Level retention (FLR).

Is that correct – are you using FLR file systems ?

First I would suggest to use the newest simulator available on support.emc.com which is 7.1.47.5

You can find that via support.emc.com by searching “VNX simulator” in Support Tools”

Please keep in mind that from 7.1. onwards some of the mapping of retention dates changes since it support retention beyond the 2038 (Unix 32bit time).

The latest VNX FLR manual has the details for that.

1) Yes the handling of zero size files changed back in 5.6.43 when append-only files were introduced

see what FLR state the file is actually in – with append only you can only append or delete

you can either look at the FLR activity log or via an engineering/support command

.server_config server_2 –v “file query cworm_state /fs1/cworm/file.txt”

2) I assume you mean a file that has infinite retention date – there it depends whether you are using FLR-C or FLR-E

With FLR-E you can shorten it once – with FLR-C you cannot change its retention date or delete

Make sure to check what the actual retention state and date is – look at the FLR activity log in the root of each fs from a NFS client or via the control station

3) Not sure – it sounds like a difference in behavior between SMB versions – are you using SMB1 or 2.0 or 3.0 ?

see “server_cifs server_2 -o audit,full” to check

Doesn’t make sense to troubleshoot with a long outdated simulator though

As a software development partner please take a look at our EMC Technology partner program (ETP) here

https://community.emc.com/community/partner/etp

Rainer

Actually 7.1.65.8 is the latest simulator – posted May 16 2013

https://download.emc.com/downloads/DL43065_VNX_File_Simulator_(OE_7.1.65.8)_-_Single_Data_Mover.zip

Hi Rainer,

2.: We are using FileMover for its main purpose HSM. If we set the modification time stamp of an existing file equal to the highest possible time value (time_t = 0x7FFFFFFF), the file cannot be set offline by the corresponding FileMover command DHSM_SET_OFFLINE_ATTRS. DHSM_SET_OFFLINE_ATTRS reports error code OFFLINE_MTIME_BAD_FORMAT if this time value is provided as parameter to the command (which we do to make sure that the correct version of the file is set offline). Is this a know restriction of FileMover or has this problem been solved in recent API or system releases?

1., 3.: We'll check this again using the newest simulator.

Thank you for your support.

Hi,

I talked to our developers and the answer is:

The 0x7fffffff is not a valid DHSM mtime since this is the maximum 32bit integer, which is a known restriction.

Rainer