Move compressed file(s) to the Bin after extraction / Move original file(s) to the Bin after compression

[nikzic]

Hi,

I just updated to Catalina and I noticed that these two options are not working any more. I tired unchecking and rechecking them but they still do not work. Can you look into this?

Thanks!

[aonez]

Hi @nikzic! Just checked and it's working for me. Does it fail always for you? Can you try for example in the Desktop?

If it fails, can you take a look at the Console.app (filtered by Keka) to see if there's any log there?

[nikzic]

Hi @aonez, thanks so much for the quick reply. I just played around with it a bit, and it seems this is happening only on iCloud folders. Since my Documents and Desktop are in iCloud, the issue is present. When I try to zip/unzip something in non-iCloud folders, everything works perfectly. Before Catalina, this issue was not present in iCloud folders. I tried disabling the option "Show warning before removing from iCloud drive" in Finder preferences, wishfully thinking that may help, but it didn't. The issue is present on both my macs. In the Console, I don't see anything related to Keka, i.e. there is no item that has "Keka" in the Process column. Any other tips? :) BTW, Keka has access to my whole disk. I also now granted it access to iCloud folders specifically, but it is still the same.

[aonez]

Reproduced! Thanks @nikzic, I'll do more testing tomorrow.

[aonez]

This is the error:

Error Domain=NSCocoaErrorDomain Code=3328 "“file” couldn’t be moved to the Bin because the volume “Macintosh HD” doesn’t have one." UserInfo={NSURL=file:///Users/user/Library/Mobile%20Documents/com~apple~CloudDocs/file, NSUserStringVariant=Trash}

[aonez]

I've reported it to Apple via the Feedback Assistant, stating that:

Calling trashItemAtURL with a path from iCloud Drive results in an error.

To reproduce:

Call trashItemAtURL with an iCloud Drive path (/Users/user/Library/Mobile Documents/com~apple~CloudDocs/file)

Result:

The call fail to move and will return an error with a message stating that the file couldn’t be moved to the Trash because the volume doesn’t have one.

Expected:

The file will be moved to the iCloud Drive trash, located at /Users/user/Library/Mobile Documents/com~apple~CloudDocs/.Trash

Catalina is half backed.

Will do a workaround, but this should be fixed by Apple. @nikzic if you can report it too.

[nikzic]

Thanks a lot, @aonez. Just reported it too

[aonez]

Already made a workaround for this, coming in next release :)

[nikzic]

Awesome! Thank you very much @aonez for this superb support!

[aonez]

@nikzic 1.1.23/24 has this fixed, could you double check it works for you?

[nikzic]

@aonez I have installed the latest version from the App Store - 1.1.24, and I still have the same issue

[aonez]

@nikzic can you check if you have a .Trash folder in you iCloud Drive?

if [ -d ~/Library/Mobile\ Documents/com\~apple\~CloudDocs/.Trash ]; then echo Yes; fi

If you do, please:

1. Enable DevLog:

defaults write com.aone.keka DevLog true

2. Restart Keka
3. Do some operation with the Move to Trash option enabled
4. Check in the Console.app if there're some messages like the one in Move compressed file(s) to the Bin after extraction / Move original file(s) to the Bin after compression #493 (comment):

[Darklocq]

On-topic: I suppose you will need to resolve issues with 10.14 and 10.15 in Keka, but I hope this does not come at the cost of the app working for everyone else. Given that the average lifespan of a high-end Mac is over a decade, lots of us will be using older versions for a long time.

An off-topic digression:

Yeah, macOS 10.14 and 10.15 really are pretty half-baked, as you say above. This "death to 32-bit!" obsession of Apple's is wreaking havoc, especially when it collides with their largely unrelated mania for radically changing how various things work, for no clear reason, with each major release. (It seems mostly to be a combination of trying to make desktop computers look and work like phones, which is just stupid, and a desire to treat users like morons and increasingly restrict what they can do without Apple's permission, which is even more stupid and verging on Android-style evil.)

Lots of us, with a whole lot of money invested in MacOS X 10.6 through macOS 10.13 applications, are not going to move to 10.14 (which only supports old apps to an extent) and 10.15 (which just breaks them all) for years. I have a 12-core Mac Pro tower which (with the amount of RAM I have in it) can comfortably run macOS 10.13, and two different Linux VMs, and Windows 7, and Windows 10 (with Skyrim!) all at the same time. So if Apple thinks I'm going to throw that machine out and buy some expensive new "black box" Mac with no internal slots or bays for my current and expensive hardware, just so I can only use apps they say I can use (and have to buy again for the most part), well, they're just smokin' crack. (I can even run modern Metal 2 games on my current box as soon as a I get a new video card for it, and even the CPUs can be upgraded a step or two. I've already got USB 3 in it and other upgrades. I'll be using the same machine for several more years.) What Apple is doing is basically Microsoft and their Windows 8 and Windows 10 all over again (around 50% of businesses still use Windows 7, because it gets the job done and the upgrade path is mega-expensive when you factor in all the licensing and IT and productivity costs).

It chaps my butt that BBEdit and various other apps are no longer supporting 10.13 and lower at all. They're just going to lose customers.

[gingerbeardman]

It chaps my butt that BBEdit and various other apps are no longer supporting 10.13 and lower at all. They're just going to lose customers.

I agree on this. I would hope that developers map support to analytics of their current users, but in the case of 1Blocker (10.15 only!) that is not the case at all which is kind of worrying.

[aonez]

@nikzic any update on the issue? I can't replicate anymore with 1.1.24 version.

I hope this does not come at the cost of the app working for everyone else

@Darklocq The idea is keeping legacy OSs compatible as long as possible. It was very sad to cut 10.6.

developers map support to analytics of their current users

@gingerbeardman & @Darklocq I only have some analytics on the website:

Dark blue : 10.15 | Green: 10.14 | Red: 10.13 | Yellow: 10.12 | Light blue: 10.11

So 10.11 is still almost 4%. 10.13 still has a long way to go.

[nikzic]

Hey @aonez, just did what you asked and I see no similar error message in the Console app! I suppose I did everything right in the Terminal? See attached and let me know if you see any issues. I am not a coder, just so you know :)

[aonez]

Thanks for the follow-up @nikzic! So there you checked that there's in fact a Trash in your iCloud Drive and activated the log mode on Keka.

Now I've found that sometimes even the workaround fails with this error:

Error Domain=NSCocoaErrorDomain Code=513 "“test” couldn’t be moved because you don’t have permission to access “.Trash”." UserInfo={NSSourceFilePathErrorKey=/Users/aone/Library/Mobile Documents/com~apple~CloudDocs/test, NSUserStringVariant=(
    Move
), NSDestinationFilePath=/Users/aone/Library/Mobile Documents/com~apple~CloudDocs/.Trash/test, NSFilePath=/Users/aone/Library/Mobile Documents/com~apple~CloudDocs/test, NSUnderlyingError=0x6000001784b0 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}

---

Can you add the iCloud Drive folder to the File Access (in the Keka -> Preferences) list and see if that helps?

[nikzic]

Hi @aonez, actually I already granted Keka access to iCloud when we first figured out the issue is with iCloud files. See attached.

The result is the same

[aonez]

@nikzic please try this build and follow these steps so I can get more information of the issue in your machine.

[nikzic]

Hi @aonez I just installed the latest macOS update (10.15.2) and this issue is no longer present for me in the latest version from the App Store. I guess Apple fixed the bug you found :)

[aonez]

You're right! I'll remove the workaround since it's no more needed. Thanks for all the feedback @nikzic!

[nikzic]

Thanks for the software, @aonez! The amount of time it saves me just by deleting compressed files is amazing. :)

[mrwinther]

You're right! I'll remove the workaround since it's no more needed. Thanks for all the feedback @nikzic!

Some of us are stuck with older OS and would like the workaround back.... :)
Im on 10.14.6 with Keka v 1.2.15

Keka is not moving extracted files to the bin. :(

Pp... please?

:)

[aonez]

@mrwinther I don't remember if the workaround ever worked, but will try to check that and test it with you.

[mrwinther]

Cool :) Thanks.

[dmuiX]

For me the function move to trash bin is not working anymore on big sur and keka v1.2.18. By that I mean its not moving my files to the trash bin, they just stay in the folder. Not sure when this happened, but I think that some former versions were working or maybe it was the upgrade to big sur that killed this function. Not sure anymore. I will try an older version from a year ago or some thing like that and report.
Update:
v1.2.5 from dec 2020 was not working
v.1.1.25 from feb 2020 was not working either
So I would say Big Sur is causing these Problems, more precisely one of the newer versions of Big Sur.
I got my Macbook somewhere in March 2020. In 2020 the function was working correctly. I think when I installed Big Sur it was working correctly, too.

[aonez]

@dmuiX it's working for me on Big Sur 11.6 (20G165). Installing 11.6.1 now to see if it changes anything.

Is this happening to you in any folder? Can you create a debug session Keka > Help > Debug > Create a debug session, reproduce the issue and share the log here?

[aonez]

@dmuiX tested without issue. Please do the above to see more information about the issue.

[mrwinther]

Its working fine now with version 1.2.18 on osx v 10.14.6

Thanks :)

[dmuiX]

thank you for your fast answer. well its happening in my download folder. will try other folders as well.

this is the error shown in the debug logs:
Error Domain=NSCocoaErrorDomain Code=512 "“Weslie.zip” couldn’t be moved to the trash." UserInfo={NSURL=file:///Users/daniel/Downloads/Weslie.zip, NSUserStringVariant=(
Trash
), NSUnderlyingError=0x60000034edf0 {Error Domain=NSOSStatusErrorDomain Code=-1407 "errFSNotAFolder: Expected a folder, got a file "}}

what does it mean?

I think I know what is going on. If I try to move files to my trash bin this isn't happening either. So this has something to do with the trash bin of my system.

[aonez]

There's some problem with your trash. The error is -1407 also called errFSNotAFolder.

Doing a quick search I've found this, maybe you can try some of those steps:
https://apple.stackexchange.com/questions/13480/error-code-1407-mac-os-x-10-6-7

[dmuiX]

Yeah figured that, too. thanks for the link. Will try what they are proposing.

For the record this helped:

cd ~ && mv .Trash .Trash.old

# now logout and re-login

[mrwinther]

Not working on 1.2.52 - 10.14.6

[foogaz]

not working on 1.2.61 (5114), macOS Mojave 10.14.6