On two occasions I have experienced a situation with our DMX installation where a user soft deletes a single file from DMX either through DMX itself or WEBdev all files and folders in DMX get deleted as well.

Has anyone seen something like this before and can suggest a means to prevent it from happening in the future?

It is probably due to lag in the menu rebuilding. Have you ever experienced it using the context menu? That is guaranteed to be tied to what you clicked on. My guess is that you used the main menu and the item still loaded was the folder (the menu refreshes every time you change the selection).

BTW, I've not seen this happen through WebDAV. Which version of DMX are you using?

We are currently running version 5.3.5 of DMX on DNN 5.6.2.

When I delete the file through WebDAV (which is a hard delete) no others are deleted. Through the context menu all files will get deleted.

One thing of note is that all files except one is reporting there size in this particular folder are being around 56MB when they are only in the KB range in size.

I did some additional testing and it appears that when I delete on of the files whose size is incorrectly stated all files will get deleted. If I delete a file that is of the correct size only that file is deleted when done through the context menu.

Meant to say

I did some additional testing and it appears that when I delete one of the files whose size is incorrectly stated all files will get deleted. If I delete a file that is of the correct size only that file is deleted when done through the context menu.

Check this from the change list:

05.03.06
Enhancement: Allow IS Search provider to determine its own local path to files (DMX-382)
Fix: License screen callbacks no longer throw error in DNN 5.6.1 (DMX-392)
Fix: Sometimes notifications would not be sent to approvers (DMX-393)
Fix: Cleanup code could delete files from other portals (DMX-394)
Fix: New Item Exception in Template UI/Single Screen edit/Non-Admins and wrong EntryId in Templated View (DMX-390)
Fix: Soft-delete of entry with bad [path] value could lead to soft delete of repository (DMX-384)
Fix: GetEntryByTitleInCollection error which may lead to failing root id selection with root pattern (DMX-385)
Fix: Net 4 framework adjustment to web.config needed for IIS 7 (DMX-386)
Fix: Subscriptions removed from UI for host users as this didn't work correctly anyway (DMX-389)

05.03.07
Fix: Notifications not attaching document to email (DMX-395)
Fix: Notifications sent to all users (DMX-402)
Enhancement: Double check correct file transfer to storage (DMX-400)
Fix: WebDAV editing of entry in absolute root not possible (DMX-397)
New Feature: Add a script to analyze the state of the file storage rather than take immediate action (DMX-396)

05.03.08
Fix: Attribute values now carry over to new versions (DMX-403)
Fix: Resolved problem with DMX urls in DNN installations in a virtual path (DMX-408)
Fix: Some logs would be written to C:\DMX (DMX-410)
Fix: Filesize as bytes now displayed correctly when less than 1 Kb
Fix: If host jumps from one portal to another it no longer loses admin rights (DMX-409)
Fix: IE Context menu no longer loads over DMX context menu in IE9 (DMX-407)

It could be that this has been fixed in 5.3.6 by the looks of it.

Peter

I'll look into the upgrade.

I did take a look at the one of the files that is being reported by DMX with an incorrect file size and the OS is reporting back the correct file size.

The incorrect file size also shows up in WebDAV.

It appears that the upgrade to the latest version of DMX corrected the problem.

Still at a loss as to why the file sizes are incorrect.

It has to do with the way it used to be calculated and how deletes and versions were handled. That could cause errors in those sizes. This should all have been ironed out by now. Note there is a script (Admin > Run Script) to recalculate all sizes in case you find it has gone wonky.