Possible KM bug with Trashing files (but probably isn't really a KM bug)

Questions & Suggestions
1

@peternlewis I encountered what is possibly a bug in KM 9.2. For a short period of time, the Trash File action didn't move files to the Trash, it actually deleted them. This is bad, I know, but I have a suspicion it might not be KM's fault. But that's based on a lot of circumstantial evidence, and semi-educated guesses. Let me explain.

A couple of days ago I bought a new 1TB SSD drive to replace my 480MB SSD drive, for editing my videos. I used Carbon Copier Cloner to move everything over to the new SSD. To the best of my recollection, the only thing I did after that with the new drive was to copy video files from my camera's SSD. I spent several days shooting video, so I didn't use the drive for anything else. At least, as far as I remember.

Then I sat down to start trimming down the video files, using a great little free program called Lossless Cut. As part of my workflow, once I've trimmed down a video file, I have a macro which trashes the original source file, and moves/renames the trimmed file.

After trimming a handful of files, I noticed that the Trash was still empty. I verified that the Trash File action was indeed deleting files instead of moving them to the trash.

So I duplicated a smallish video file in Finder, then right-clicked it and selected "Move to Trash". It went to the trash like it was supposed to. Then I tried the Trash File action again, and it worked this time - it moved the file to the trash.

I haven't had any problems since then - which has only been a handful of files at this point, but I think it's enough to know the problem's solved.

Here's what I think happened: When Carbon Copy Cloner cloned the drive, the .Trashes folder on the new drive either hadn't been created yet, or didn't get linked correctly (or something like that). So when you were using the Trash File API call, it wasn't trashing the files, but deleting them.

But as soon as I used Finder to trash the file, it fixed whatever was wrong with the .Trashes folder.

Again, this is all speculation and WAGs, but I think it's reasonable. So, assuming I'm close to right, I wonder if KM could somehow verify that Trashing a file really will trash it instead of just delete it, and throw an error if that's not the case. I'm not suggesting you do anything fancy, but I'm thinking there might be an API way to check that.

Anyway, there's my tale. This is such a huge outlier case that I doubt many other people would ever come across it, but I wanted to let you know anyway.

2

The code that trashes the file is using the API:

[[NSWorkspace sharedWorkspace] recycleURLs:@[[NSURL fileURLWithPath:source]] completionHandler:^(NSDictionary *newURLs, NSError *error) {…}]

and reports the error as a notification if it fails.

So for what you describe, the system would have to choose to delete the file and not report it as a failure of the API - which it might well do I suppose.

I don't know that there is much I can do about reporting this. It seems somewhat excessive to then go and find the deleted file and ensure that they are trashed and exist and report an error otherwise, especially if I can't verify the behaviour.

3

Huh. According to an answer to this Stack Overflow post, the docs say this:

Some volumes may not support a Trash folder, so these methods will report failure by returning NO or nil and an NSError with NSFeatureUnsupportedError.

So I would have thought you'd get an error. Oh well, that's the way it goes sometimes.

1 Like
4

But in this case, the volume might support the trash folder, and the trash folder might not have been created, and that might not be a case the coders handled.

Or perhaps, with the trash folder not being there, the files were moved somewhere else (the temp folder for example), and so the system did not consider that to be an error.

5

Yeah, I get that there's all sorts of reasons this wasn't handled by the coders. It's kind of the true definition of an outlier case. Thanks, Peter!

1 Like