NapAgent service not running for file copy

[dcb]

I thought I had my head around all of this and with the new file copy methods it was finally making sense. I'm now getting a 500 error when trying to copy files. The best I can find is an error message that says:

Code Select Expand

{
"error":{
  "code":1003,
  "message":"Windows COM method or interface failed.",
  {
   "hresult":"8027000C",
   "message":"The NapAgent service is not running."
  }
}
}

I don't have a NapAgent service to be running.

Could be I'm in the wrong place, but when I tried the v1/filesystem/file/move I got a message that I couldn't move across drives (which makes sense with the folders I'm testing with) so that makes me think this is the right error message to be looking at.

I'm using 2017.9.4 (64-bit) on Windows 10 Pro 1703 (Creator's Update). From what I can find on the web, the NapAgent services isn't even a thing with Windows 10.

My filenames are in the form C:\Users\Wendy Buchan\Dropbox\Camera Uploads from David\2017-09-06 18.10.43.jpg when output on the console by this code.

Here's the code.

Code Select Expand

IMWS.get('v1/filesystem/folder/scan', {
    path: 'C:\\Users\\Wendy Buchan\\Dropbox\\Camera Uploads' + foldersToCopy[nextFolderIndex],
    filemask: '*.mov,*.png,*.jpg,*.mp4, *.crw, *.dng, *.raw'
}).then(function(response) {
    //console.log(JSON.stringify(response,null,2));
    var index = 0;
    var numFiles = response.folders[0].files.length;
    response.folders[0].files.forEach(function(f) {
        var fullName = f.folder + f.fileName;
        console.log(fullName);   
        $('#filename').text(fullName);

        // Update the progress bar
        var perc = Math.floor((index * 100) / numFiles);
        $('#pbar').css('width',perc + '%');
        $('#pbar').text(perc + '%');
        index++;

        IMWS.post('v1/filesystem/file/copy', {    // FAILING HERE
            source: fullName,
            target: 'M:\\rips\\temp'
        }).then(function(response) {
            // Worked :-)
            // response contains the data received from IMWS.
            console.log(JSON.stringify(response,null,2));

        },function(error) {
            // Failed :-(
            // error contains information about the problem.
            console.log('Oops. Something went wrong: ' + error.status);

        });
        },this);
    nextFolderIndex++
    moveNextFolder();
});

Thanks in advance.
David

[Mario]

IMWS internally hands over the file move/copy/rename operations to Windows IFileOperation COM class.
The error codes and messages returned by IMWS come straight from these built-in Windows functions. I don't know what a NapAgent service is either.

When I ask Google, it tells me that this is Microsoft's "Network Access Protection Agent" (https://technet.microsoft.com/en-us/library/cc735503(v=ws.10).aspx and Wikipedia https://en.wikipedia.org/wiki/Network_Access_Protection)


A)  Your script iterates over the returned files and calls the v1/filesystem/file/copy in a loop. It does not wait for the last copy operation to complete.
This basically means that you are trying to copy all files at once (within a few milliseconds).
IMWS has internal locks to 'sequentialize' such operations, but maybe this is still too much action for Windows...?
Do you get the same result when you only copy one file?

B)  You seem to copy to a network drive (M:)? And the error message is mumbling something about Network Access Protection. Did you try to copy to a folder on your local hard disk?

C)   You are copying from a folder which is under the control of the Dropbox service running in the background. This usually does not cause trouble, but who knows...

To analyze:

1.  To ensure that your code is good, try to copy from a normal local folder to another local folder (c:\source to c:\dest) for example. If this works even with many source files, your code is OK and has no issues.

2.  If 1. is successful, copy from your Dropbox folder to c:\dest.

3.  If 2. is successful your code is good and the problem is most likely the network location M:

I'm not ruling out that there is a problem in my code which deals with the Windows the IFileOperation  COM class. I had no problems copying/moving files to a Windows Server or NAS box running SAMBA. And I just tried to copy files from my Dropbox folder, which also works.

When I ggl for IFileOperation 8027000C I don't get much so this seems to be something unique.

[dcb]

Thanks Marco. It may very well be the copy tasks falling over the top of each other. M:\ is an internal, non-network drive but there was the same problem with C:* to C:* as well. I'll have to play around to get a single file scenario and test that then work out a way to get syncronous file copies. Would that be something like this? (Forgive the syntax shortcuts. I need a reference copy to get it right)

Code Select Expand

nextFile {
    IMWS.copy.....(
    ).then(function(response) {
      index++;
      nextFile();
    )};
}


Will mean I have to break that for each loop I have going at the moment but I think I can do that easy enough as all I really needs is the index into the files list.

[dcb]

Hi Mario,

Found it.    The 'name' argument to 'v1/filesystem/file/copy' isn't really optional. It needs to be specified (my original code didn't) or appended to target.

So that's either:

Code Select Expand

IMWS.post('v1/filesystem/file/copy', {
  source: fullName,
  target: 'C:\\temp\\',
  name: f.fileName
});

or

Code Select Expand

IMWS.post('v1/filesystem/file/copy', {
  source: fullName,
  target: 'C:\\temp\\' + f.fileName,
});

Specifying the target as the directory without the name fails. My guess is that although the error message is completely misleading it's caused by copying a file on top of a folder name.

Same deal for 'v1/filesystem/file/move' (local drive to local drive)

Still got to work out the synchronicity around the file copies but they all went through.

Cheers,

David

[Mario]

Eh,

the "name" parameter is not supported. Target must be a fully-qualified file name.
My bad. The IMatchLib.js documentation has it right, the automated documentation still mentions the old name parameter. I had switched that after switching to the modern IFileSystem COM interfaces in IMWS, which require fully-qualified names.

I have updated the JSON documentation for the next release.