Save issues with filesystem workspace

[Dokkaltek]

I found some issues when working on a workspace that was saved in filesystem instead of in application:

• When you import a collection from postman to restfox it won't let you rename the folder, and if you change the text with the properties popup open, it won't let you close it until you leave the name back to the original name it had.
• If you have any script on the scripts panel of a request, the next time you close and open restfox, those scripts will be gone, no matter if you created the request from restfox, or imported it from postman. The same will happen to any plugins you had on the collection.
• If you export a collection from restfox in filesystem mode, when you try to re-import it on another workspace it will have deleted the plugins and the scripts.

[Dokkaltek]

Sample restfox collections. Both were exported with a sample folder with a sample plugin and a sample request with a sample pre and post script.
test-export-in-app.json
test-export-in-filesystem.json

[flawiddsouza]

Regarding point 2 and point 3, can you try the latest version: https://github.com/flawiddsouza/Restfox/releases/tag/v0.32.0? I pushed some fixes. I seem to have broken the plugin retrieval code when I made some changes in the last update. Plus I found an issue in the workspace plugins code, so you should see your scripts and plugins correctly now. Let me know if you're still facing the same issues. Please make sure you're on v0.32.0.

When you import a collection from postman to restfox it won't let you rename the folder, and if you change the text with the properties popup open, it won't let you close it until you leave the name back to the original name it had.

I'll look into this. Seems like a weird bug.

[Dokkaltek]

Thank you, it seems like the scripts are being imported correctly now.

As for point 1, it seems like it won't happen with small collections which don't have embedded folders inside, since I couldn't reproduce it exporting on postman format from restfox, but I created a postman collection with some embedded folders inside where I could reproduce the issue.

Here is the sample postman collection:
Sample Postman collection.postman_collection.json

[flawiddsouza]

Hi @Dokkaltek, I tested with your given postman collection on a file workspace and was unable to reproduce the issue:

vokoscreen-2024-12-16_11-33-02.mp4

Can you give me the exact steps or a recording of the issue you're facing?

[Dokkaltek]

I recorded the issue. It seems to not allow renaming the root folder of the imported collection, but it doesn't have any issue with renaming child folders inside that root folder.

It also won't allow you to move the folder to any other folder you may have created later in the workspace.

I tested on 2 machines, and it happens on both for me, both on version 0.32

2024-12-16.09-51-59.mp4

[flawiddsouza]

"EPERM: operation not permitted" is a file permission issue. Also I see that you're on windows. I'll check on windows once as well. The video I shared was from a linux system.

Can you try creating the workspace in a different folder, possibly a different drive? I assume the issue is specific to your system. Maybe that specific onedrive folder.

Since you've tested on two systems, just want to confirm, if you were creating the workspace in the onedrive folder in the 2nd system as well?

[Dokkaltek]

I tested outside the onedrive folder on both systems, both directly on the user profile folder and on a folder directly on C:/, but had the same result. Both systems use windows.

I also tested creating a new folder directly on %appdata%/Restfox, where the configuration files of Restfox are (where it should have permissions), and it gave the same error.

I also tested running restfox as admin, but it didn't make any difference. I also made sure to not add spaces on the folders just in case, but the error it gave was the same.

[Dokkaltek]

Oddly enough it does create the folders of the workspace where you tell it to, and you can create other folders like normal, but it won't allow you to rename the damaged postman folder nor move it on a folder you create manually on restfox later.

[Dokkaltek]

After some more testing it seems like it doesn't happen specifically to postman imports, but it happens to folders created directly on restfox as far as it has subfolders in it.

I found some stackoverflow issue that might be relevant:
https://stackoverflow.com/questions/64964891/node-js-fs-module-rename-directory-that-has-subdirectories-eperm-exdev

[flawiddsouza]

After some more testing it seems like it doesn't happen specifically to postman imports, but it happens to folders created directly on restfox as far as it has subfolders in it.

After what you said, I thought it was weird that it was happening only for postman imports. Seems like it's a general issue on windows. Folders with sub folders are the culprits.

I'm using fs.renameSync as that seemed like the correct thing to rename a folder. This works fine on macOS and linux. But not on windows sadly it seems.

Thanks for the thorough testing. Also thanks for the link. Should help.

[flawiddsouza]

I found this: paulmillr/chokidar#1380. We're using chokidar to watch files and keep them updated in the application. I think we're hitting this issue rather than a windows bug. I mean it is a bug specific to windows but it is being caused by chokidar. This seems like it will be tricky to fix but it needs to be fixed.

[Dokkaltek]

Maybe as suggested on the stackoverflow issue possible solution it would be better to just create a new folder with the name changed, move everything from the old folder to the new one recursively and then delete the old folder. That way the chokidar issue wouldn't have the underlying fs issue that comes from node for renaming folders with subfolders.

Since on Linux and Mac it works as it should, checking the running OS to perform the workaround rename in case it's windows, and otherwise keep using the old fs.renameSync method.

So something as suggested of:

rename(path: string, newPath: string) {
    if (fs.existsSync(newPath)) {
      throw new Error('Already exists');
    }
    
    if (fs.lstatSync(path).isDirectory()) {
      fs.copySync(path, newPath);
      fs.rmdirSync(path, { recursive: true });
    } else if (fs.lstatSync(path).isFile()) {
      fs.renameSync(path, newPath);
    }
  }