macOS: input/output error on folder copy/delete

[Evgeny]

I'm trying to delete a folder win and get an input/ouput error (see screenshots below from Path Finder and Finder)


I can't copy it either, though I can rename it
On a Windows machine I can copy the folder just fine (and I can delete the copy on macOS; haven't tried to delete the original folder on Windows not to lose the valuable example of an error)

Selected system info

• macOS 10.12.6
• Sirikali (today's git version) used to mount
• gocryptfs v1.4.1-2-ged046aa-dirty; go-fuse v20170619-14-g204b45d; 2017-08-24 go1.9rc2
• Volume info

[rfjakob]

Do you have something logged in syslog? (the syslog viewer is called "console" in macos)

[rfjakob]

Oh and can you try copying the folder in the terminal? Maybe we get more info on what goes wrong.

[Evgeny]

Terminal

$ cp -r win win2
cp: cannot access 'win': Input/output error

So nothing new :(

I've also started to see some other errors as well:

1. In Finder trying to copy&paste the folder: The Finder can’t complete the operation because some data in “” can’t be read or written. (Error code -36)
2. In Finder trying to create a new folder (fails every other time): An unexpected error occurred (error code -36).
3. In PathFinder on file/folder creation (again, fails every other time):

Errors 2) and 3) seem to have disappeared after I've unmounted and mounted the drive, even though the original folder is still cursed

Console
Found 4 logs in System reports, please check them in this gist

There is also output of errors from the Devices console log during the the terminal cp -r win win2 operation console errors

Haven't found anything else, but Console if a big dump :), so if you know where else to look, let me know

[rfjakob]

Ok, I looked through the logs, this was the only interesting entry I found. Note that "err=5" = input/output error, so looks closely related. But I was hoping to find log entries from gocryptfs itself.

kernel osxfuse: filehandle_get: failed for win (type=0, err=5, caller=<private>)
kernel osxfuse: filehandle_get failed in open (type=0, err=5)

But, no problem. We can turn up the log level. Can you mount on the command line using:

gocryptfs -fg -fusedebug -nosyslog CIPHER PLAIN

This should get you a detailed log of all operations. Then retry the "cp -r win win2" in another terminal window and post what happens in the log? Thanks!

[Evgeny]

Here you go, two logs, one for a terminal copy command, the other for a PathFinder copy&paste
(strangely enough the terminal command creates a copy of this folder despite the error and this copy is "normal", I can copy/move/delete it in either terminal or finder)

P.S.
I see a reference to invalid entry ".DS_Store", could it be that I was testing Blueharvest, which removes these ".DS_Store" turds on non macOS drives (in this case, on a mounted GoCryptFS drive) and somehow this interferes with the GoCryptFS index? Just a guess
Just FYI the win folder and its parent are empty, there are no ".DS_Store" or any other files

P.P.S
By the way, the terminal ls ./win command (from win's parent path) also fails with ls: cannot open directory './win/': Input/output error and a similar error log

[rfjakob]

Yes, you caught it!

OpenDir "tBDzkpW9Z27vxo9rhJafcg/LiL88ih2y91SeWJFHL0cyA/J0EGgl1Vy4RE53e7KtGCiw":
  invalid entry ".DS_Store": illegal base64 data at input byte 0
OpenDir "tBDzkpW9Z27vxo9rhJafcg/LiL88ih2y91SeWJFHL0cyA/J0EGgl1Vy4RE53e7KtGCiw":
  all 1 entries were invalid, returning EIO

There is a .DS_Store file in the encrypted folder! gocryptfs tries to decrypt the file name, fails (obviously) and returns an I/O error. Delete the .DS_Store file and you should be good.

[Evgeny]

Ah, I see. Those persistent hidden macOS turds :(
I guess I was checking out this folder in Finder for some reason and it was happy to do its dirty business (actually, I wasn't testing BlueHarvest at that time, and anyway it's not recommended for macOS drives, so isn't much of a help anyway)
Given how hard it is to avoid these files from being created on a macOS, would you please add a fix so that GoCryptFS would simply ignore these files instead of trying to decrypt them?

[rfjakob]

Yes I agree, it's pretty hard to avoid those files. I have just pushed two changes that should fix both reading and deleting the directory - could you test if it works for you?

[Evgeny]

Yep, seems to be working, now I can delete folders even if the corresponding encrypted folders have .DS_Store files in them (and the folders are otherwise empty)
Thank you for a prompt fix!