lsd
lsd copied to clipboard
"cannot access '.'" error on Windows
Installed from the latest master branch commit:
- on a substituted drive:
C:\Users\thorsten\.cargo\bin\lsd.exe
cannot access '.': The access control list (ACL) structure is invalid. (os error 1336)
- on C:
C:\Users\thorsten\.cargo\bin\lsd.exe
cannot access '.': The specified domain either does not exist or could not be contacted. (os error 1355)
On further inspection, this seems to be bug in relation to files created in a Cygwin environment on Windows
- native Windows: okay
> New-Item -Name test-win.txt -ItemType File | Out-Null
> lsd --long --icon=never test-win.txt
.rwx------ VORDEFINIERT\Administratoren REDNAILS\Kein 0 B Sun Jun 21 13:50:16 2020 test-win.txt
- Cygwin: not okay
> touch test-cyg.txt
> lsd --long --icon=never test-cyg.txt
lsd: .\test-cyg.txt: The access control list (ACL) structure is invalid. (os error 1336)
- show difference between the two files
> ls -Al
total 40
-rw-rw-r--+ 1 thorsten Kein 0 Jun 21 13:52 test-cyg.txt
-rwxrwx---+ 1 Administratoren Kein 0 Jun 21 13:50 test-win.txt
Owner (thorsten
vs Administratoren
) and permissions (664
vs 770
) differ. We give the group (Kein
/None) execute permission.
Now it works:
> chmod g+x test-cyg.txt
> lsd --long --icon=never test-cyg.txt
.rwxrwxrwx REDNAILS\thorsten REDNAILS\Kein 0 B Sun Jun 21 13:52:10 2020 test-cyg.txt
If lsd
is unable to parse file's ACL created under the same user, this is a bug in lsd
.
Cygwin creates correct ACE's. Non-canonical, yes, but they are correct ACE's according to the specification.
"+" at the end of POSIX permissions mask means you have to use tools such as getfacl
(or native icacls
) to explore actual permissions. POSIX simple mask is merely an approximation in such case.
Also, the fact your files have different owners suggests that you actually running your Windows code under Administrator user, not your current user.
-
lsd
reports an OS error (os error 1336
). Whether that directly refers to the ACL or to whatlsd
would like to do is something I cannot tell, yet I accept your view. -
Administratoren
is actually a group ("administrators"). PowerShell'sNew-Item
assigns ownership to the group while Cygwin'stouch
makes the user the owner. That's standard behaviour.
Anyway, I'd love to see it fixed.
I am also having this error, but have not used Cygwin for a very long time. I do not have to be using a mapped drive for this to happen. Any time I invoke lsd
(ver 0.17.0) under pwsh
(ver 7.0.3), Powershell
(ver 5.1.18362.752), or even cmd
(ver 10.0.18362.959 with clink
ver 0.4.9), I get this exact error message:
lsd: .: The specified domain either does not exist or could not be contacted. (os error 1355)
Any fix yet?
This means, one of your your object's ACE refer to a SID that cannot be resolved at the moment.
Perhaps, the disk was used in(with?) a different domain previously (you reinstalled the OS?).
I am experiencing similar issues. Like @sql-sith, I have Cygwin installed but have not used it in years. Would uninstalling Cygwin correct the problem?
The output I am getting is:
lsd: .\dev: The access control list (ACL) structure is invalid. (os error 1336).
lsd: .\dircolors-solarized: The access control list (ACL) structure is invalid. (os error 1336).
lsd: .\dotfiles: The access control list (ACL) structure is invalid. (os error 1336).
lsd: .\Homestead: The access control list (ACL) structure is invalid. (os error 1336).
lsd: .\karlin-mintty-colors-solarized: The access control list (ACL) structure is invalid. (os error 1336).
lsd: .\mavnn-mintty-colors-solarized: The access control list (ACL) structure is invalid. (os error 1336).
I recognize these directories as ones that I created a long time ago, probably back when I used Cygwin. I don't know from where lsd is reading these, but I'd like it to stop, if at all possible.
@SturmB , no, your error is due to lsd bug. See https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-files
Oh, so uninstalling Cygwin won't help either, eh? That's a shame. Well, I certainly hope there will be a bug fix for this someday. Thanks for the info, @AnrDaemon.
I'm having the same error code 1336 as well. I installed lsd
via scoop install lsd
.
Here's me trying out lsd
in 4 shells but to no avail:
Then here's WSL2 (I"m using Cmder):
WSL2 works because I installed it via sudo dpkg -i lsd_0.20.1_amd64.deb
More info:
mintty 3.4.7 (x86_64-pc-cygwin) [Windows 19042]
Hope it's useful.
What made you think that different shell could make results different? The problem in the lsd itself. In case of WSL2, the directory is network mounted and its ACL entries are likely mangled. Or Linux lsd is not making the same checks as Windows one.
Any updates on this? Works fine in Power Shell 7.1 and Cygwin64, but getting (os error 1336) on git bash terminal.
HI guys, the same thing happens to me, any workaround?
Hi @hologramrp and others meet this error, we have introduced a new permission mode, --permission attributes
in windows, this might help, could you try the newly released v1.1.1
Bonjour @zwpaper and folks! how are you guys? Hope it doing good ;)
YEAH, now it's working, thanks!
Actually just updating was not enough, I had to clean my previous instalations. So, because I installed via cargo, winget and scoop, First I was needed to do in terminal:
winget remove --id lsd-rs.lsd
scoop uninstall lsd
cargo uninstall lsd
After then, I install the newly version from the master branch.
cargo install --git https://github.com/lsd-rs/lsd.git --branch master
Close the terminal, and open again and it works ; )
(Using Powershell 7.4.1, on a Windows 11 Pro, Version: 22H2)