We have a discrepancy in our development and production content servers (11g) in the way that expired content is automatically handled. - In dev, the original file is deleted and replaced with a file of the same name, except with a "~1" appended to the end of the web location. The original file is no longer available from it's original web location. - In production, the same process occurs, but the original file is still accessible via the original web location, which indicates it was not deleted.
It's been a struggle to track down the source of this configuration. Is this an out-of-the-box feature, or does this have to be configured on it's own?
Yes, this functionality is the out-of-the-box feature. By default each content item's revision has meta-field 'Expiration Date' which defines when expiration will occur.
Expired content revisions are marked correspondingly in the database (revisions.dstatus='EXPIRED') thus they will not be accessible in application via search, but can still be found by administrator (Content Management -> Expired Content).
Expired revision files are not deleted from weblayout, but renamed instead as not latest revisions - marked with ~{number} postfix.
Expired revision files are neither deleted from vault nor renamed.
Lets say we have 2 revisions (dID=31026 and dID=31025) of a picture 009139 (dDocName=009139). Both revisions are expired. In this case:
DID DDOCNAME DSTATUS ---------------------- ------------------------------ -------------------- 31026 UP_009139 EXPIRED 31025 UP_009139 EXPIRED
\ucm\weblayout\groups\public\@test\documents\multimedia\up_009139~1.gif \ucm\weblayout\groups\public\@test\documents\multimedia\up_009139~2.jpg
\ucm\vault\multimedia\@test\31025.gif \ucm\vault\multimedia\@test\31026.jpg
Regarding your issue with prod - make sure you had no further revisions after the expired one (in this case this revision will be, of course, available)