mkdirsSync fails misleadingly if directory exists, but cannot be stat-ed.

[igor-petruk]

https://github.com/jprichardson/node-fs-extra/blob/master/lib/mkdirs/mkdirs-sync.js#L43

I have a docker container which mounts the directory as a host path bind mount. The operation fails with a misleading error.

/usr/local/lib/node_modules/app/node_modules/fs-extra/lib/mkdirs/mkdirs-sync.js:45
        throw err0
Error: EEXIST: file already exists, mkdir

There is probably something wrong with the permissions, but the directory fails to be stat-ed. I can investigate deeper to provide what is the exact exception err1 is swallowed by

      try {
        stat = xfs.statSync(p)
      } catch (err1) {
        throw err0
      }

but we should make a more fine-grained check here and depending on what is the error, throw either err1 or err0.

[RyanZim]

Yeah, this is weird, I wonder what error is getting thrown here. Also, what platform is this?

[igor-petruk]

This is Linux on Raspberry Pi 3. In addition to all, the backing host path on GlusterFS, which is know to return unusual things from stat operations. Anyway, why don't we just check of EEXISTS, as we already do for ENOENT? Why check again with an extra stat? I might be missing something. Is there a case where EEXISTS does not mean that the job is done? ср, 19 вер. 2018 о 15:35 Ryan Zimmerman <notifications@github.com> пише:

…

Yeah, this is weird, I wonder what error is getting thrown here. Also, what platform is this? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#625 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABWTIOSOvisj79XqRtmbTgBQb5k1TGoGks5uclYqgaJpZM4Wv5lA> .

[RyanZim]

The purpose of the stat call is so that we can check if it's actually a directory. If it's a file with the same name, throwing EEXISTS is appropriate.

[Manvel]

moveSync seems to also fail with similar Error: EEXIST: file already exists, link ... error.

[RyanZim]

#619 may fix this.

[RyanZim]

If this is still reproducible on Node 10.12+ and latest fs-extra, please comment here, otherwise, will close and assume fixed.