Permission Denied Error when Trying to Create Directory in Root of D Drive

[Tendaliu]

Here's the error message that I received:

Writing output files.. Error: EPERM: operation not permitted, mkdir 'D:'

[rotemdan]

What was the exact command line you used? Can you provide more details?

The way that output files are written, is that they are first written to a temporary directory, and then a move operation is performed to the target location. This is to ensure there are no partial/broken files left on the target directory if the operation is aborted, or fails for whatever reason.

It may be that there is a problem writing to the temporary directory, or , to the target location.

The write operation also creates any directory needed to open the target file. For example, if you specify E:/someDir/hello/myfile.mp3 and path someDir/hello doesn't exist, then it would create these directories. However if the drive E doesn't exist, you may get a weird error that tells you it wants to create the drive.. :)

I need more information..

[Tendaliu]

C:\Users\Sunda>"C:\ProgramData\node-v18.17.0-win-x64\echogarden.cmd" align "D:\测 试\文稿分割.m4a" D:\文稿匹配.txt D:\文稿匹配文稿匹配.srt --subtitles.maxLineCount=1 --subtitles.maxLineWidth=20 --plainText.paragraphBreaks=single
Echogarden v0.10.5

Prepare for alignment.. 170.9ms
No language specified. Detecting language.. 131.5ms
Language detected: Chinese (zh)
Get espeak voice list and select best matching voice.. 146.5ms
Selected voice: 'sit/cmn' (cmn, Chinese)
Load alignment module.. 0.6ms
Create alignment reference with eSpeak.. 1938.9ms
Compute reference MFCC features.. 137.7ms
Compute source MFCC features.. 88.0ms
DTW cost matrix memory size (120s maximum window): 68.5MiB
Align MFCC features using DTW.. 404.0ms
Convert path to timeline.. 1.4ms
Total alignment time: 3023.8ms

Writing output files.. Error: EPERM: operation not permitted, mkdir 'D:'

[rotemdan]

Thanks for reporting.

I was able to reproduce this. This happens when the target directory to write a file is the root directory of a drive.

Before I write the file, I call ensureDir to create the target directory path if it doesn't exists. However, it turns out that the ensureDir method (from the fs-extra package) doesn't know how to handle the root directory of a drive like D:\, so an error is produced when it is given to it. I'll make a special case to detect the case where the root of a drive is used as path.

For now you can just use some directory as the target like D:\abcd\myfile.txt.

I'll get the fix up soon.

[rotemdan]

Turns out that working around the issue with ensureDir wasn't enough.

I found a serious bug in the move method in the fs-extra package, when a file is moved to the root directory.

I isolated a simple test case:

import { move } from "fs-extra"

console.log("Moving..")
await move("D:\\test\\test.txt", "D:\\test.txt")
console.log("Done")

It hangs forever (stuck at "Moving.."). Debugging into the code shows that it gets stuck in some sort of a loop trying to fix file permissions.

I've opened an issue on the node-fs-extra tracker.

It's incredible that something as obvious as this hasn't been reported yet. This library had 86,665,872 downloads in the last week and has 9,000 stars.

In the meantime (whatever time it'll take them to fix it), I'll have to work around this bug for this particular special case.

Thanks for the feedback, you've actually found a significant bug in an external library!

(also, I found a small issue with building of temporary paths.. which is now fixed)

Update: I submitted a second bug report on the node-fs-extra repository, for ensureDir not handling root paths correctly and not checking for the existence of a drive.

[rotemdan]

fs-extra had 86,665,872 downloads in the last week and has 9,000 stars.

Isn't that incredible that no one has reported such simple error cases? (there have been more than 1000 issues reported in the past)

The reason may be that it is rare that files are written to root directories.

Node.js is a platform that is mostly used for server applications, not command line applications (although, as you can see, it turns out it can be very effective for CLIs). When a developer encounters this kind of write permission error, they usually "blame themselves" and simply avoid it by writing to a non-root path instead.

However, here I'm trying to build a "fool-proof" tool where the user can specify arbitrary paths on the drive, including even the root paths (which does make sense if the drive isn't a system drive).

Anyway, even trying to workaround this problem, I'm getting into serious permission errors with other methods as well, now with copyFile (I'm getting a permission error even when I copy to the root directory of a non-system drive).

I'm working this out with several chatbots to try to come up with solutions that don't require administrator permissions. I'm not sure if I'll succeed at all.

[rotemdan]

The problem doesn't happen on the root directory of all drives, only drives where the root directory doesn't have write permissions for non-administrator users (or the user Node.js uses, in general).

Based on GPT-4, it's likely that Node.js is running on a different user than what you experience in the windows explorer (where likely you're using a user with Administrator privileges), and it simply doesn't have permission to write in the root folder of D:\.

It may be fixed on Windows by adding permissions for non-administrator users on the root directory (haven't fully tested it, since takes too much time to run for me, asit goes recursively to all subdirectories):

Anyway, after spending about 4 hours on this, at least I got some bug reports to the fs-extra developers. However, from experience it's possible they would never actually fix them, or reply on the issue at all.

I did actually make some modifications to catch these kind of situations better, and prevent hangs when calling move, so the code would be more robust to edge cases such as these. I'll publish the changes on the next version later today.