Issue with RadFileExplorer: "A file with a name same as the target already exists!"

[Kavindu]

Hi,

I'm using RadFileExplorer in a project that includes file version control. Occasionally, when attempting to save a new version of a file, I receive the alert:
"A file with a name same as the target already exists!"

This issue seems inconsistent — it doesn't appear limited to a specific file type, but I've noticed it more frequently with image files or files that have numbers in their names.

I came across a possible solution in this File Explorer as a Version Control issues. in UI for ASP.NET AJAX | Telerik Forums, where it was suggested to modify the GetFIle method to always return null. Here's the method :

public override Stream GetFile(string url)
{
    string virtualPath = RemoveProtocolNameAndServerName(url);
    string physicalPath = this.GetPhysicalFromVirtualPath(virtualPath);
    if (physicalPath == null)
        return null;

    if (!File.Exists(physicalPath))
    {
        return null;
    }

    return File.OpenRead(physicalPath);
}

if it is okay to overriding this method to always return null? Is it a safe and recommended approach to prevent the "file already exists" error in version control scenarios?

[Rumen]

Hi Kavindu,

The RadFileExplorer is designed to preserve the filename of uploaded files. If a file with the same name is uploaded, the new file upload will be canceled with a warning. This is a built-in configuration and cannot be changed with any settings or properties of the RadFileExplorer.

However, it is possible to override the StoreFile method used by the RadFileExplorer, and implement custom logic to change the filename as desired.

Sample code and a functional sample application is available at the resource below:
RadFileExplorer - Rename file on upload

The approach overrides the StoreFile method to rename files upon upload, ensuring that each version has a unique name. This approach avoids conflicts and preserves the integrity of file uploads.

Alternative approach: The GetFile method in your custom FileBrowserContentProvider is indeed the key part here. As advised by Fiko in the File Explorer as a Version Control issues forum, the GetFile method is used by RadFileExplorer specifically to check if a file exists. Overriding it to always return null effectively tells the control that the file does not exist, which bypasses the default file existence check that triggers the "A file with a name same as the target already exists!" message.

This approach is considered safe in the specific context of version control, where your backend manages the actual file storage and versioning logic, and where the explorer is not expected to enforce file uniqueness on its own. However, keep in mind:

• If any other functionality in your application relies on GetFile to fetch actual file content (e.g., for download or preview), returning null could break that functionality.
• This override only impacts the file existence check for RadFileExplorer; it does not handle backend storage or versioning, which should be fully managed by your custom logic.

So, if your version control system fully decouples file storage from the explorer, and you're only using RadFileExplorer as a UI tool, it is a valid solution.

Regards,
Rumen
Progress Telerik