I checked recursive and clicked synchronize files in the file manager for DNN 4.9 as some folders had gone missing from the list.

Everything updated ok in the file manager, all folders appeared, but throughout the portal now NONE of the links to file attachments work. They all result in the error listed below.

What is the the fileticket and how is it generated/encoded? There seems to be no reference to it in the dnn FILES table. Hopefully it is encoding the file name and not some randomly assigned id or value, as it should always uniquely point to the correct file. If so, why is it broken/not found? It appears it references the dnn generated FileID field in the files table, which must have changed.

Manually relinking a few seems to fix the problem for those links by changing the fileticket to a new number, so it looks like all the filetickets were changed. Manually relinking is not really an option for 2500+ links. Especially if it can happen again.

Any help on how to bulk update these links to match the new fileticket numbers is greatly appreciated. We're in serious trouble, so thank you to anyone who can help.

Error Message: 

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.

Source Error:

[NullReferenceException: Object reference not set to an instance of an object.]
   DotNetNuke.Common.Utilities.FileSystemUtils.DownloadFile(Int32 PortalId, Int32 FileId, Boolean ClientCache, Boolean ForceDownload) +66
   DotNetNuke.Services.FileSystem.FileServerHandler.ProcessRequest(HttpContext context) +1454
   System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +181
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +75

Server Error in '/' Application.

---

Object reference not set to an instance of an object.

Version Information: Microsoft .NET Framework Version:2.0.50727.3053; ASP.NET Version:2.0.50727.3053 

depending on your module, file links are usually stored either by (relative) path or file id, in the second case, if the id's get reassigned, the links will be broken. I am not aware of a reassignment during manual recursive sync, but there have been issues reported in DNN 4.8/4.9 with scheduled sync, therefore I strongly recommend to disable the file sync job in host :: scheduler.

If IDs get reassigned, the only chance you have is to restore the previous folders and files table and identify issues manually in the database before running the sync task.

I was afraid of that. Not the best design in the world, at least for us. Would rather have the links point to the file path. If files are moved, then at least a search and replace are possible. As it is, we cannot search for old filetickets and replace with new, as the old are lost, and we don't know the new.

I am not sure what the original problem was or what caused (apparently) all the id's to change with the manual sync, so can't lay blame with certainty. (I didn't check for broken links before syncing.)

Thank you for the feedback.