xxoo/node-fswin

nodejs fs extensions for windows

node-fswin's Issues

nodejs v4

setAttributes readonly and archive

If I set a file or folder to IS_READ_ONLY:true and then get its attributes (using find()), IS_READ_ONLY is false.

If I set a file or folder to IS_ARCHIVED:true and IS_READ_ONLY:false and then get its attributes, IS_ARCHIVED is true (expected), but IS_READ_ONLY is true.

var fs = require("fs");
var fswin = require("fswin");
var path = require("path");

var file1 = path.resolve("file1.ext");
var file2 = path.resolve("file2.ext");

fs.writeFile(file1, "", function(error) {
    fswin.setAttributes(file1, {IS_READ_ONLY:true}, function(success) {
        fswin.find(file1, function(result) {
            console.log( result[0].IS_READ_ONLY );  //=> false (??)
        });
    });
});

fs.writeFile(file2, "", function(error) {
    fswin.setAttributes(file2, {IS_ARCHIVED:true, IS_READ_ONLY:false}, function(success) {
        fswin.find(file2, function(result) {
            console.log( result[0].IS_ARCHIVED );   //=> true
            console.log( result[0].IS_READ_ONLY );  //=> true (??)
        });
    });
});

v3.21.903: Electron: A dynamic link library (DLL) initialization routine failed

Hi,
I upgraded fswin to version 3.21.903 in my Electron. And I got an error in production build, pointing to fswin:

A dynamic link library (DLL) initialization routine failed

Here's the commit: aleksey-hoffman/sigma-file-manager@ce9a70e
See this issue for more details: aleksey-hoffman/sigma-file-manager#139

I didn't see this error on my computer, but one of the users encountered it. I downgraded to version 3.21.107, and according to the user, the error went away when they installed the build with the revert commit: aleksey-hoffman/sigma-file-manager@3b4a4f5

Error loading using devtool (Electron)

Greetings,

First off thanks for the awesome module! I have been using it a bit in my project and am hitting a snag when I try to use it in the devtool debugger. In particular, I get this error:

Q:\Data\Don\Git\phylo\node_modules\fswin\index.js
The specified procedure could not be found.
\\?\Q:\Data\Don\Git\phylo\node_modules\fswin\6.x.x\x64\fswin.node

I recently upgraded to latest of everything to make sure that wasn't the issue:

> node -v
v7.4.0

> npm -v
4.0.5

> devtool -v

devtool 2.3.0
electron 1.4.3
node 6.5.0
chrome 53.0.2785.113

I also removed node_modules and ran a fresh npm install. Curiously, the error I was getting before all that was "Module did not self-register" (#11) but now I get the above.

I suspect this is an issue with Electron which is also a big target for my work.

Any ideas?

dirWatcher options are invalid

fswin.dirWatcher.options duplicates fswin.dirWatcher.events:

I copy-pasted the example code from this docs section, and it has issues related with the problem i described before:

Tip: To temporary fix this you can change options object structure like this:

const options = {
  WATCH_SUB_DIRECTORIES: true,  // watch the directory tree
  CHANGE_FILE_SIZE:      true,  // watch file size changes, will fire in 'MODIFIED' event
  CHANGE_LAST_WRITE:     true,  // watch last write time changes, will fire in 'MODIFIED' event
  CHANGE_LAST_ACCESS:    false, // watch last access time changes, will fire in 'MODIFIED' event
  CHANGE_CREATION:       false, // watch creation time changes, will fire in 'MODIFIED' event
  CHANGE_ATTRIBUTES:     false, // watch attributes changes, will fire in 'MODIFIED' event
  CHANGE_SECURITY:       false  // watch security changes, will fire in 'MODIFIED' event;
};

P.S. Thanks for awesome lib

getCompressedSize: get size of inaccessible files

Hi @xxoo is it possible to make getCompressedSize function return the size even for inaccessible files?

I calculated the size of all files in C:\Windows and got 1.9 GB with getCompressedSizeSync while the File Explorer showed 27.2 GB in the properties window.
I assume the difference is due to inaccessible files.

getAttributes segfault

First of all, congratulations on the N-API release! It looks like it was a pretty large effort!

I do have one issue to report however. Any calls to getAttributes() results in a segmentation fault. I'm also using setAttributes() which seems to work, and getAttributesSync() also seems to work.

$ node -e "require('fswin').getAttributes('src', function (result) { })"
Segmentation fault

Node 10.10.0
fswin 3.18.909

Use nan or ffi

As per #3, I got my fswin binary downloader working in Node v0.10 but due to changes in V8's API, I cannot get the binary to work in node v0.8 or v0.11.

Would it be possible to update fswin to use nan to prevent this?

How to check if binding is broken?

In a library I've written that wraps fswin, I've been thinking of using this:

try {
    fswin.getAttributes(...);
} catch(e) {
    if (e.message === "The specified procedure could not be found.") {
        // binding error
        child_process_attrib_fallback(...);
    } else {
        // expected error
        throw error;
    }
}

I think this is a Windows error. Are there any other errors that I can check for in the event that fswin has loaded (./x.x.x/arch/ exists) but fails to run? I'm trying to be very thorough with my lib and load a shell fallback if anything happens (due to the nature of bindings).

Can it be built with the latest version of Node.js?

Hi. I'm facing an issue using a library that depends on an older version of fswin.
I am considering forking, patching, or creating a custom solution, but is the latest version of fswin buildable with the latest Node.js? (v20-21)

non-7zip download link

I was trying to write an "fswin-binary" module today that would download the link on your wiki page, but because it is *.7z, there is currently no way for me to extract it. Would you consider uploading a *.tar.gz instead?

Typescript support

It would be really nice if this library could ship its types. :)

New functions

I wanted to ask, have you ever considered expanding this module by adding more functions for working with file system and drives?

For example:

• getLogicalDriveList
• watchDriveList (to detect when drive list changes)
• getDriveInfo (memory type, name, file system, etc.)
• getUsbDevices
• ejectDrive
• setDriveLabel
• copyToMtpDevice
• readMtpDevice

Maybe some functions from this systeminformation module?
It's a good module but it's really slow since it's using Powershell calls instead of C++:

• It takes 100ms to get the drive list
• And it doesn't encode strings in UTF-8, which means you cannot use it if drives have non-ASCII characters in their name

This module could become really popular if it had a lot more functions.

fswin fails to build on Linux or MacOS

Shouldn't node-fswin generate a dummy .node file so it can be required from different operating systems?

Linux:

[Error: Error: Not a valid ELF file: /home/vsts/work/1/s/out/app/node_modules/fswin/node/x64/fswin.node

MacOS

[Error: Error: /Users/runner/work/1/s/out/app/node_modules/fswin/node/x64/fswin.node: file is neither a fat binary file nor a Mach-O object file

Async callback is lacking error as first argument

The async methods in the library don't follow the general Node callback paradigm of the first argument provided to the callback being an error object if an error occurred, or null if the method was successful.

I understand that you previously closed issues regarding error handling (#10), but even a raw error or simply passing null always would at least fall in line with expectations compared to other Node async methods, though it would be a breaking version change obviously.

functions don't provide or throw errors

node "fs" package throws errors on sync functions and provides an error argument in async functions.

console.log( fswin.setAttributesSync("./non-existent-file", {"IS_HIDDEN":true}) );  //-> false

The above should've thrown an error.

package.json tags

I couldn't find the package.json in the repo, so I couldn't send a pull request.

I think it'd be beneficial to you and the library if you added an "fs" tag to the package.json file

setAttributesSync() is not working for folder

folder: E:\projects\test:

+ README.md
+ file1.txt

var fswin = require('fswin');

// Working for file
fswin.setAttributesSync('E:\\projects\\test\\README.md', {IS_READ_ONLY: false});

// Not working for folder
fswin.setAttributesSync('E:\\projects\\test', {IS_READ_ONLY: false});
fswin.setAttributesSync('E:\\projects\\test\\', {IS_READ_ONLY: false});

does not work with io.js

It looks for a ./2.0.x/ dir which does not exist. v1.0.x will undoubtedly have the same issue.

This would come in handy: nodejs/node#493

Node 8.x support

Uncaught Error: Module did not self-register.

Uncaught Error: Module did not self-register.
      at Error (native)
      at Object.<anonymous> (C:\projects\winattr\lib\binding\index.js:2:13)
      at Object.change (C:\projects\winattr\lib\whichLib.js:25:20)
      at switchLib (C:\projects\winattr\test\util.js:198:12)
      at C:\projects\winattr\test\util.js:53:3
      at FSReqWrap.oncomplete (fs.js:82:15)

https://ci.appveyor.com/project/stevenvachon/winattr/build/job/93nr8xhqxqvamlw7

Add node tests and appveyor integration

for each function, etc

getAttributes() ?

Would be nice to have. Is it possible?

Node 10 support

I'm getting Error: Cannot find module './node/10.x.x/x64/fswin.node' when trying to require fswin. And indeed the node folder in the fswin package directory only contains up to 9.x.x. I'm seeing the same result installing with either yarn or npm.

Environment:
node 10.5.0
npm 6.1.0
yarn 1.7.0
node-gyp 3.7.0

Undeclared identifier IO_REPARSE_TAG_GVFS identifier when building on Windows 10 1903 18362.592

D:\0> npm i fswin

> [email protected] install D:\0\node_modules\fswin
> node-gyp rebuild


D:\0\node_modules\fswin>if not defined npm_config_node_gyp (node "C:\Users\shf\AppData\Roaming\npm\node_modules\npm\node_modules\npm-lifecycle\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild )  else (node "C:\Users\shf\AppData\Roaming\npm\node_modules\npm\node_modules\node-gyp\bin\node-gyp.js" rebuild )
在此解决方案中一次生成一个项目。若要启用并行生成，请添加“-m”开关。
  fswin.cpp
  win_delay_load_hook.cc
D:\0\node_modules\fswin\src\find.h(321,36): error C2065:  'IO_REPARSE_TAG_GVFS': undeclared identifier (compiling source file ..\src\fswin.cpp) [D:\0\node_modules\fswin\build\fswin.vcxproj]
D:\0\node_modules\fswin\src\find.h(331,36): error C2065:  'IO_REPARSE_TAG_GVFS_TOMBSTONE': undeclared identifier (compiling source file ..\src\fswin.cpp) [D:\0\node_modules\fswin\build\fswin.vcxproj]
gyp ERR! build error
gyp ERR! stack Error: `C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\MSBuild.exe` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onExit (C:\Users\shf\AppData\Roaming\npm\node_modules\npm\node_modules\node-gyp\lib\build.js:194:23)
gyp ERR! stack     at ChildProcess.emit (events.js:305:20)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:275:12)
gyp ERR! System Windows_NT 10.0.18362
gyp ERR! command "E:\\SDK\\NodeJS\\node.exe" "C:\\Users\\shf\\AppData\\Roaming\\npm\\node_modules\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js" "rebuild"
gyp ERR! cwd D:\0\node_modules\fswin
gyp ERR! node -v v13.5.0
gyp ERR! node-gyp -v v5.0.5
gyp ERR! not ok
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\watchpack\node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\glob-watcher\node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\@types\gulp\node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\shf\AppData\Roaming\npm-cache\_logs\2020-02-15T11_07_33_985Z-debug.log

After digging into the source I found that the following two macro definations not exist in winnt.h

So I fixed it by adding the following two lines into "find.h" and then it can be compiled successfully

#define IO_REPARSE_TAG_GVFS                     (0x9000001CL)
#define IO_REPARSE_TAG_GVFS_TOMBSTONE           (0xA0000022L)

Update Electron support

I recently updated my Electron app FreeMAN to v1.8.x. This package seems very coupled to certain versions of Electron, and does not currently support v1.8.x.

Rather than packaging compiled binaries, you could distribute the source code that consumers could then build using electron-rebuild. I suppose doing the same with Node would be optional, given the way the index.js is currently written.

The quick yet less elegant solution would be to add v1.8.x Electron support in the same way you have other versions.

OneDrive offline files have IS_OFFLINE: false attribute

Hi, thanks for making this module.

I found a problem with getAttributes functions, they return IS_OFFLINE: false for files located in OneDrive directory with status "Available when online". They have compressedSize === 0

Compiling for electron fails

Running on Win10, Node 7.8.0 and node-gyp 3.6.0. Following the guide found here running this command
node-gyp rebuild --target=1.6.2 --arch=x64 --dist-url=https://atom.io/download/electron produces this error.

Electron App - Uncaught Error: The specified module could not be found

npm version: 6.11.3
node version: 12.3.1
electron version: 5.0.2
winston version: 3.2.1
fswin: 3.18.918
OS: Windows

This is run time error occurred while running the Electron Desktop App on Windows.

Watch OneDrive folder that is not automatically downloaded

Thanks a lot for this library, I use it for some things in clipboard-sync. But there is another thing which I'd like to use, which is apparently not supported yet (if even possible to):

OneDrive has the Files on demand feature, which allows to keep track of the files but only download them when necessary.

This feature can be enabled or disabled by right clicking the folder and toggling the Always keep on this device option.

I'm testing fswin.dirWatcher to check if it can watch files without having them downloaded first (other file watchers like Chokidar will only fire events for files which are actually downloaded).

But it does not seem to work.

When Always keep on this device is enabled, this the the list of events I can get from fswin.dirWatcher on a file creation:

"1-test.txt~RF1b9046.TMP" is added. it could be created or moved to here.
"1-test.txt~RF1b9046.TMP" is removed. it could be deleted or moved from here.
"1-test.txt" is added. it could be created or moved to here.
"1-test.txt~RF1b9046.TMP" is removed. it could be deleted or moved from here.
"1-test.txt" is modified. this event does not contain any detail of what change is made.

But as soon as I disable Always keep on this device from OneDrive, no more events are fired at all when I create the file from another computer.

It's funny though, because removed events are still being fired even if the file was never downloaded if I delete the file from another computer.

Maybe there is something that can be done to start capturing such events as well?

Support FILE_ATTRIBUTE_SPARSE_FILE

There's a lot of use for having sparse files enabled on Windows, which doesn't seem to be possible in node's regular FS API.

Specifically, the FILE_ATTRIBUTE_SPARSE_FILE attribute toggles this.

Specifically, this would be useful for random-access-file which is often used for storing large sparse files.

Would a PR that adds this attribute to setAttributes.h be welcome?