fix: reopens files that were opened when dragging and dropping files or folders

[tarikutk]

Summary:

1. it opens previously opened files when dragging and dropping a file or a folder.
2. it prevents VSCode from opening a folder as a file when moving a folder from one folder to another folder. it instead opens the file that was opened in that folder

Testing:
verified it opens previously opened files instead of opening a folder as a file.

Fixes #1478

[Copilot]

Pull Request Overview

This PR fixes file reopening behavior when dragging and dropping files or folders in the Content Navigator. It ensures that previously opened files are reopened at their new locations after a move operation, and prevents VSCode from incorrectly opening folders as files.

Key Changes:

• Modified the moveTo handling logic to track closed files as an array instead of a boolean
• Added a new calculateNewFileUri method to compute new URIs for files that were moved
• Implemented logic to reopen all previously opened files after a successful move operation

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[scottdover]

Hey @tarikutk . Is there a github issue associated with this PR? Or rather, what issue is this solving?

[scottdover]

Fwiw, this is sas server specific. Anything that is specific to connection type should happen in the adapter if possible.

[tarikutk]

okay. I updated that. I am importing from the adapter instead.

[tarikutk]

Hey @tarikutk . Is there a github issue associated with this PR? Or rather, what issue is this solving?

yes @scottdover, there is a GitHub issue associated with it. I attached the link now in the PR message. it is #1478.

[scottdover]

Sorry for the delay in getting back to this one. At a high level, this is how the code is structured w/r/t file access.

• ContentDataProvider exposes the data view to the ui via a treeview
• ContentModel is responsible for handling the business logic related to file CRUD operations
• ContentAdapter is an interface that defines the specific methods used in ContentModel to provide data back to the user
• There are a few implementations of ContentAdapter
  • ItcServerAdapter: For server files via an itc connection
  • RestServerAdapter: For server files via a rest (viya) connection
  • RestContentAdapter: For sas content via a rest (viya) connection

Your implementation has itc (relativePath.replace(/^~fs~/, "") as an example) & rest specific code (/(\/files\/[^&]*)/ as an example) in ContentDataProvider. Any code that is specific to a certain connection type should be nested in the relevant adapter.

[tarikutk]

I updated @scottdover .

[tarikutk]

the commit for itcServerAdapter is something which I was not able to test. and the last one is just to fix typescript issues. please let me know if itcServerAdapter works and if the fix for typescript breaks things. I will revert those if needed. Thanks

[scottdover]

Should this be optional? It should if this isn't an issue that affects SAS content. If it does impact sas content, I would expect to see changes in RestContentAdapter as well

Also, super nitpicky, but these functions for this type are all alphabetized. Will you alphabetize this new function?

[tarikutk]

yes. I think it should be optional. restContentAdapter is not calling it at all because closeFileIfOpen is returning true rather than array of closed files for restContentAdapter.

[scottdover]

It feels like there's a lot of duplication between this and the rest server adapter implementation. From what I could tell, the three pieces that are unique for this function and the other are:

• How directory separators are determined
• how to extractPathFromUri
• how to generateNewFilePath (basically, lines 352-371 here, 482-505 in the other file)

With that in mind, I'm wondering if this method can look more like this...

const extractPathFromUri = (uri: string) => {
      /* process things */
      return '';
    };
    const getDirectorySeparator = (basePath: string) => {
      /*
      use getDirectorySeparator in ItcServerAdapter, or return
      the separator for rest
      */
    };
    const generateNewFilePath = (
      oldBasePath: string,
      closedFilePath: string,
      newItemUri: Uri
    ) => {
      /* Do specific calculation for ITC or REST */
    };

    return calculateNewFileUri(
      extractPathFromUri,
      getDirectorySeparator,
      generateNewFilePath,
    );

With the above, extractPathFromUri, getDirectorySeparator, and generateNewFilePath are unique for ItcServerAdapter or RestServerAdapter are unique, while the code moved to a shared calculateNewFileUri function would contain the duplicated bits (NOTE: This is an oversimplification to some extent and there may need to be more parameters passed into the shared function)

[tarikutk]

I broke down the functions to utils instead of passing those functions as a prop. passing 6 parameters and passing 3 of them back to those functions was not looking good. I added them in utils of a specific adapter instead.