save us from our own trailing periods about node-convergence-archive

[cjihrig]

I don't think we should do this in core. While Node can create a file that you can't remove using Explorer, you're able to remove the same file programmatically. This seems like something that would make a nice userland module though.

[shenanigans]

This might be a new win10 issue, and I'm (rather hopelessly) attempting to raise the issue with Microsoft, but I haven't had tons of luck removing them programmatically either. edit but good point, I'll go check if graceful-fs is doing this yet

[cjihrig]

I tested on Windows 7, using fs.unlinkSync(). I'm not sure if it works on Windows 10. Calling for backup...

cc @piscisaureus and @orangemocha

[shenanigans]

That's...... odd. I fought with this quite a lot yesterday. When I shut the system down last night my stubborn directory still stood. Looking at it again now, about 24 hours later, it's disappeared all the way back to a distant parent directory. Making a new badly-named file I can't reproduce the bug at all. My face right now dot jpeg.

I'm starting to think this might have just been a Win10 bug all along. Wouldn't be the first filesystem-related screwup.

[piscisaureus]

Node bypasses some of the sanity checks/rules that windows normally enforces - primarily in order to support filenames longer than 260 characters. And I'm aware that this creates trouble sometimes. However you should never get completely stuck -- you should be able to delete any file created by node ... with node :).

I'm adamant to doing more path sanitization on windows - we could remove trailing dots and whitespace, for starters, as I'm sure windows normally does that. I don't know exactly what other transformations it does.

Starting point for making these changes would be path._makeLong().

[orangemocha]

Will test this on Win10

[silverwind]

I'm not sure if this information is still up to date, but there's a historical list of system-reserved file/folder-names that can't be modified through Explorer:

http://blog.onetechnical.com/2006/11/16/forbidden-file-and-folder-names-on-windows/

[ChALkeR]

@shenanigans A few questions here:

1. Doesn't rm \\?\D:\whatever. (or rmdir \\?\D:\whatever., if it's a directory) work? If it doesn't, what error does it produce?
2. Is it possible to create a file/directory using Node fs module that you couldn't later delete using Node fs module? If yes, could you share a testcase?
3. What exactly are the differences in Windows 10 compared to previous versions? What «old methods» are you referring to?
4. What would be the expected behaviour in your opinion?

Edit: AFAIK, the answer to question (1) is «yes, it works», and to question (2) — «no, it's not». If so, the problem is quite minor, but if you prove me wrong — it would make it a bit more serious.

[shenanigans]

@ChALkeR Windows native del is handling this ok, today. The "old method" I mean is the incantation rd \s "\\?\c:\etc". I basically can't reproduce the issue right now (and feel properly silly about it) but whenever one of these commands fails it acts like the file or directory cannot be found.

In answer to number three, at least as an example, what's new about Windows 10 on my system is that every time windows update queues a reboot it logs a bad hard drive sector and crashes. I'm less than comfortable with the integrity of its filesystem at this point.

As for expected behavior, the existing behavior for improper filenames seems acceptable to me.

> fs.writeFileSync ('*()_*$*', 'cheddar cheese')
Error: ENOENT, no such file or directory 'c:\data\*()_*$*'

The file descriptor fails to open and cannot be written. That fault may be easy to produce artificially for filenames that just should not be written. And I've heard a rumor that writing sketchy filenames can get antivirus software angry about your script...

[rvagg]

be aware that this discussion may be lost to history as this repo is slated for possible removal, if this is important please discuss @ https://github.com/nodejs/io.js