Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[linux] EISDIR: illegal operation on a directory #92

Open
haggholm opened this issue Feb 4, 2020 · 6 comments
Open

[linux] EISDIR: illegal operation on a directory #92

haggholm opened this issue Feb 4, 2020 · 6 comments

Comments

@haggholm
Copy link

haggholm commented Feb 4, 2020

trash (invoked, in my case, via trash-cli) does not seem to work on directories in Linux (in my case, Ubuntu 19.10).

$ trash {src,test,build}/**/*.{js,d.ts,map}
Error: EISDIR: illegal operation on a directory, copyfile '/builds/build/es6' -> '/root/.local/share/Trash/files/c862ddbe-a1f8-4589-b545-fe260f81e2e9'
@sindresorhus
Copy link
Owner

I don't have Linux available, so I won't be able to look into this, unfortunately.

@haggholm
Copy link
Author

I can’t say I’ve entirely solved it yet, but I took some time to try to at least narrow the issue down.

The problem seems to be in lib/linux.js, specifically the call to make-dir, and related to permissions. I happen to keep the project I’m encountering this in on a separate partition from my home directory, on a scratch drive /mnt/scratch/bla/bla/.... /mnt/scratch is writable only by root, not my user account. Since there is no .Trash... directory on this partition, it seems trash attempts to create one, and fails due to permissions. If I copy a checkout of trash-cli byte for byte, it runs fine from under my home directory and fails under /mnt/scratch. (And I was confused for a while because the tests of trash itself pass just fine even after I added a failing case for trash-cli—but then I realised it creates and works from a temp dir.)

To be honest, I do not know what the behaviour ought to be when trashing something on this partition. Is it supposed to fail? Should it perhaps use my default trash directory, as in xdgTrashdir.all()? Should it try to create a ‘local’ one and fall back to the default? Is my setup just basically broken in terms of trash directory setup?

I’m also not sure if this is the same behaviour I’ve seen in all cases/on all machines, but it's definitely a potential cause of failure. Please let me know if I can be of any more help—running test cases or whatever.

@mattcorner
Copy link

Also experiencing this in a docker container.

@jakedowns
Copy link

experiencing this in Ubuntu 18.04 on WSL2 on Windows 2
i swear it used to work just fine. odd

@daniel347x
Copy link

In case anyone isn't aware, you can bypass the alias via:
\rm

@gRizzlyGR
Copy link

Had the same issue, but it was a permission problem.

I did transpile the code and so a build folder was created. In the Dockerfile I had COPY . ., so this build folder was copied in the docker, and the OS panicked since the user who created the folder was different.

HTH

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants