The Problem: Reassigned File IDs
Some time ago our web team encountered an annoying and potentially devestating issue on one of our production DotNetNuke servers.  It seemed that, overnight, hundreds of DNN file links became corrupted.  The result was that many document links in our Documents modules no longer linked to the target files but instead linked to...nothing.  The target files were still present on the server but the DNN file ID values were now different.  Affected files had been reassigned new DNN file IDs as if the files were brand new to the DNN instance.  We checked logs in DNN, IIS and on our servers but found no clue as to what caused the file IDs to change.  Stranger still, only a few hundred of the thousands of file IDs had been affected.

We did not want to revert to the previous day's backup copy of the database since we would lose any new data introduced since the backup.  Instead, we repaired the broken file links by updating all old file ID references with the new file IDs (we created some custom database scripts for this).  After our file IDs were back in order, we spent a bit more time snooping around our systems and checking our favorite DNN forums but found no answers to our file ID issue.

Over the next couple of weeks the same issue occured several more times.  The issue would occur both at night and during the daytime working hours but never on an identifiable schedule.  Sometimes only a few dozen IDs would be affected.  Once several thousand (!) were affected.  Each time we were able to use our custom scripts to repair the damage but were still no closer to discovering the cause.

The Cause
One of our developers eventually noticed a time correlation between a scheduled task on another server and our instances of reassigned file ID.  We learned that our operations department had scheduled a file backup process to run twice a day -- once at night and once during the day. 

DNN "Auto-Sync" Feature
Our file backup process locked entire directories of files while performing backups.  Normally this should not be an issue but DNN has a HOST feature called "Auto-Sync File System".  (In DNN 4.3.x it is the very last HOST option under "Other Settings".)  The "Auto-Sync" feature runs on a timer and causes DNN to re-index all files under the PORTALS directory.  This is useful in environments where files may be directly added under PORTALS (using Windows Explorer or FTP, for example) rather than through the DNN user interface.  Using the DNN interface, files are assigned file IDs automatically.  When NOT using the DNN interface, files will not appear to certain modules (such as Documents) until a file sychronization has been performed (file IDs have been assigned).  The Auto-Sync feature takes care of such situations without any action from the user.

When "Auto-Sync" did its thing, AND when our file backup process happened to be backing up anything under the PORTALS directory at the same time, DNN would be unable to see the "locked" directories and would assume that those files were deleted.  DNN would then dutifully remove those file entries (and assoicated file IDs) from the DNN database. 

That explains why the old file IDs dissapeared, but where did the new IDs come from?  Well, the next time Auto-Sync ran (every hour in our case) the formerly "locked" directories would now be unlocked as our file backup process had moved on from those directories.  DNN would now see those as "newly added" files and would assign new file IDs.

The Fix
Our solution was simple -- since we did not want to give up or otherwise modify our file backup solution we instead turned off the DNN "Auto-Sync" feature. 

Note that by turning this off we were then required to use the DNN "File Manager" (available to both Admin and Host) to perform a "synchronize files" operation (in order to assign DNN file IDs) anytime we manually moved files to any directory under the PORTALS directory. 

NOTE:  If you'd like to turn off "Auto-Sync" but have non-ADMIN users who need to manage files, check out our blog posting HERE about exposing the FILE MANAGER admin module to non-ADMIN users.