#[nexe pkg] existsSync returns true even if the folder is deleted after the first existsSync check

69 messages · Page 1 of 1 (latest)

dense umbra
#

I delete a folder using spawnSync command, and I can verify that the folder is deleted, but execSync still returns that the folder exists, how can i get over this issue?

heady rampart
#

There’s no cache

#

Why are you using child_process over fs?

dense umbra
#

Good morning @heady rampart , becuase of a bug with fs, it's not able to delete directories

heady rampart
#

No, it’s not. If you are using child process, fs isn’t involved at all

dense umbra
#

this is the bug that I am facing with the fs

#

I check if the dir exists, then proceed with the shell command to delete the folder, then I run check if the dir exists, those checks still giving me that the dir exists even if it's not when I check it on the side

heady rampart
#

Okay, so you have two threads for the same issue, I’m closing this one

dense umbra
#

no, this thread is about existsSync

#

The other one is focused on deleting meanwhile this one is focused on checking if directory exists

heady rampart
#

There is no fs cache, everything is a direct libuv call

#

Again, you are trying to perform a non standard operation, deleting files with a command, not fs

#

It’s an issue with the command, it’s probably slower than the file read

#

Try using Node.js’s file system instead of child process

dense umbra
#

Either way if I delete whether internally or externally, if the file doesn't exist, then existsSync shouldn't return true, at the end of the day, they are all separate things

#

Ok, let's put it this way, I have an ongoing process or job that runs every while, if a folder is deleted by user, then should it still return true? So, we can't really link both together

heady rampart
#

I suppose, and I’m not an expert on the file system, If you delete a folder externally, and you call fs in the same ‘tick’ it might return true instead of false.

dense umbra
#

and you call fs in the same ‘tick’ it might return true instead of false.
What do you mean by same 'tick'? Is this about same timing?

heady rampart
#

Well, the event loop has an order, if you are deleting the file at the same time that you are checking if it exists, there might be a discrepancy

dense umbra
#

After folder is deleted, I have a loop that runs a 10 second wait on each iteration and existsSync to see the response feedback, I can see true every single time for 100 seconds split by 10 iterations, the folder does not exist when I checked during the checks period. So, no it's not a timing issue.

bright spade
#

you are definitely doing something wrong if it still says it exists 100 seconds after it was deleted.

heady rampart
#

Have you tried other methods to check if the file exists in libuv? Do they fail?

dense umbra
#

@bright spade , can you please clarify? The situation is pretty much straight forward on my side:

if (existsSync(folderPath)) {
  deleteSync(folderPath);
}

for (let i = 0; i < 10; i++) {
  if (!existsSync(folderPath)) {
    break;
  }

  const ms = (i + 1) * 1000;
  this.logger.info(`${folderPath} still exists, waiting ${ms} milliseconds`);
  await ThreadHelper.sleep(ms); // I can validate the folder is not there anymore
}

Node version: v22.21.0

dense umbra
bright spade
#

what is deleteSync?

dense umbra
#

It's described here #1434751224712003584 message , but this shouldn't be related, a folder no longer exists then existsSync should return false

bright spade
#

if you're already using modules (or in an async IIFE), why are you using the sync methods?

#

I'm not reading that mess. that is 100% unnecessary

#

use unlink. be done

dense umbra
#

I wish @bright spade , but I have to, there is a clear bug in rmSync and native fs functions

#

unlink doesn't remove recursive folders

bright spade
#

sorry, rm

dense umbra
#

it's there, and it fails

bright spade
#

it doesn't fail...

#

and rmSync isn't rm

dense umbra
# 
if (pathStats.isDirectory()) {
        rmSync(path, {
          force: true,
          recursive: true
        });
      } else {
        unlinkSync(path);
      }
    } catch (rmEx) {
      logger?.warn(`Failed to delete ${path}, resolving to removeSync due to ${(rmEx as Error).message}`);
      try {
        removeSync(path);
      } catch (removeEx) {
        logger?.warn(`Failed to delete ${path}, resolving to rimraf due to ${(removeEx as Error).message}`);

Fails on my end all of them

bright spade
#

why are you testing if it's a directory?

#

just delete

#

be done

dense umbra
#

how can I "just delete" when rmSync, removeSync and even rimraf fail?

bright spade
#

they don't fail...

dense umbra
#

I will repeat myself again, they do fail on my side. See the other thread for their issue, please let us keep this thread about existsSync

bright spade
#

why don't you look at that thread instead? you were told why you get that error. it's user error

dense umbra
#

Can we please keep this thread about existsSync, please post your questions there in the other thread

bright spade
#

you're using like 20 different fs libraries and crap

#

this is such a convoluted mess for zero reason

#

I have no questions. this is an XY problem. you're doing something wrong. good luck!

dense umbra
bright spade
#

if 20 different libraries don't work, wouldn't you guess the problem is elsewhere instead of just putting together this pointless mess and asking questions that don't make sense?

dense umbra
#

because they all fail with the same error, pls get off this thread

bright spade
#

this question should be closed. there is no fs cache. you are doing something wrong if files are not being deleted when you use proper methods

dense umbra
#

existsSync returns true even if the folder is deleted after the first existsSync check

heady rampart
#

Heya! I’ve read over @bright spade’s lovely help for you, and I agree this thread should be closed.

as mentioned, the original problem was solved (there’s no fs cache), and the rest of the question isn’t something we can help you with here, as.

  1. This is an XY problem. https://xyproblem.info
  2. You already have a thread open, which, within itself, is an XY problem
  3. We’ve answers your original question
  4. you haven’t been really receptive to our answers. If node:fs tells you the file exists, that means that libuv thinks the file exists. If libuv thinks the file exists, I’m pretty sure it exists, and plenty of libraries would probably agree (https://github.com/libuv/libuv/blob/v1.x/LINKS.md)
GitHub
libuv/LINKS.md at v1.x · libuv/libuv

Cross-platform asynchronous I/O. Contribute to libuv/libuv development by creating an account on GitHub.

trim silo
#

Reopened following #help-chat message

#

I delete a folder using spawnSync command, and I can verify that the folder is deleted
how are you deleting the folder, and how are you verifying? have you tried other tools that use libuv to cross-check, as mentioned above?

dense umbra
trim silo
#

as the other functions by nodeJS are failing
could you clarify what you mean by that?

dense umbra
#

In this thread, I just want to focus on existsSync

trim silo
#

the code you linked back to is still referencing a lot of extra stuff (deleteSync, mainly, but the others as well)
could you make an mcve?

dense umbra
#

I am working on this at the moment.

dense umbra
trim silo
#

could it possibly be something to do with nexe then?

dense umbra
#

It is, I can confirm 100% now.

#

But why node version made a difference, this is very strange issue!

#

[nexe pkg] existsSync returns true even if the folder is deleted after the first existsSync check

heady rampart
dense umbra
#

maybe, I don't know @heady rampart , I have just migrated from using existsSync to shell command using spawnSync and it works like a charm, at this moment nexe + this new change (if you are correct) are broken