Error NSCocoaErrorDomain Code=4 when using the delete action

Tips & Tutorials
1

Scratch-Single.txt

I am using:

HARDWARE:
Computer: iMac (Retina 5k, 27-inch)
Processor: 3.3 GHz 6-Core Intel Core i5
OS: Mac OS 11.3 (Big Sur)

SOFTWARE: KB Maestro 10.0.2

I have had a macro that has been running for several months without error. While running this week, it gave a "NSCocoaErrorDomain Code=4" message (see enclosed images displaying the action causing the error and the error itself from notifications). The error occurs when recursively deleting a directory.

Based on forum post below, I began to troubleshoot where the problem might be.

~/Desktop/Last-Upword-Backup/UpWord Notes

Troubleshooting:
I manually typed in the filenames in the actions below as recommended in the forum post above.

(1)
Deleted and recreated KB Maestro action:
Set Variable saveFolderNameVar to Text ~/Misc/Security Backups.noindex/UpWord Notes/UpWord Notes-%ShortDate%

Tested. Result: NSC error

(2)
Deleted and recreated KB Maestro action:
Recursively delete file ~/Desktop/Last-Upword-Backup/Upword Notes

Tested. Result: NSC error

(3)
I then proceeded to narrow down the folder/directory in which the error might be appearing. I have narrowed it down to one directory. I enclose a listing (output from 'ls -lR') of all the files in the directory. I have looked at this in BBedit (Option: show invisible), but I cannot see anything wrong with the contents of the directory.

Can anybody suggest a way to narrow down the source of this error?

This seems to be an ongoing problem with KB Maestro actions.

I can provide a copy of the macro etc. if required.

Thank you for your assistance.

John Hamill

Enclosed:



https://www.dropbox.com/s/llsq67scosdq62d/KB%20Maestro-FolderContents?dl=0

2

You've got some "odd" characters in your file names, eg the not-quite-a -: in the first 3 Alfred lines and the not-quite-a-/ in the Greenflare (line 60) -- Uniode Fullwidth Colon and Unicode Fullwidth Solidus, respectively.

Try a couple of test directories with/without file names using those characters and see if that's the problem.

3

Thanks for that. But it is almost definite that this will occur again. I am the owner of all of these files and a recursive delete should not really look at the contents of the files, should it?

Do I need to consider using a shell script?

Many thanks.

4

I found that the error was caused by a single file. This was a plain text file created in Textedit.

I had locked this file within Textedit however. I use voice control extensively and sometimes lock files to ensure that erroneous text is not inserted when uttering voice commands.

It was this Textedit "lock" that produced the rather obscure "NSCocoaDomainError = 4" message. The unix "ls -l" output is the same for a file with the lock and without a lock. It is only in the Finder that you can see a tiny lock on the file icon.

I will take a note of this for the future.

Thank you for your help in any case.

5

Nice catch -- I hope I didn't waste too much of your time with the bum steer about file names...

To make amends, here's a one-liner to take care of those locked files before you run the delete action. You should change startDir to the full path to the directory you want to start deleting from -- in the above case, '"/Users/johnhamill/Desktop/Last-Upword-Backup/UpWord Notes"' (use the double-quotes so you don't have escape those space characters).

cd startDir;find . -flags uchg -print0 | xargs -0 -n1000 chflags nouchg

Put that in an "Execute shell script" step before the deletion and it will:

  1. Change directory to your startDir (that reduce the length of the arguments find passes to the exec command, reducing your chances of an "argument too long" error
  2. finds all the files (starting in the current working directory, ie the one we just charged to) that are locked and passes their paths to xargs -- the print0 stops it using a space character as a delimiter, meaning you can use spaces in file names
    3 xargs takes that list and, for each item, runs chflags nouchg -- the "unlock" command. -n1000 again lists the number of arguments passed to avoid the "too long" error.

Find is recursive, so this will go through all the subdirectories too. The whole is non-destructive, so if your Unicode-character file names do cause any problems (it didn't on the few I checked) there will be an error but no data loss.

The whole runs pretty quickly, so wouldn't add too much time to your macro if you always ran it on a "preventative" basis, even when there were no locked files.

6

Thank you for that. Will try.