Hi,
Can we keep the locked items where they are instead of being removed to the trash folder when deleting a bunch of items?
Currently, locked items won’t be removed from Trash unless explicitly told to do so. I find this function somewhat confounding for two reasons,
“locked” items, by definition, are not supposed to be easily swept into Trash in the first place, we have them locked because we don’t want them gone.
it’s hard to relocate them back to where they originally were, especially when there are too many of them coming from different directories.
So it’d be great if there can be a “Put Back” function in the Trash, or an option to keep the locked items where they are without being removed. Looking forward to your reply!
We’ll consider this for future releases. Moving items to the trash can be undone, by the way. At least until the database gets synchronized or is closed.
Just to chip in here; whilst I understand the request, I actually use and appreciate the system as it is now. I have numerous scripts which are able to delete files (e.g. expired documents). Some of them remove the locking of the file before moving it to trash (because they act on files of relatively low importance, for example). Others don’t, giving me the option to review the files before finally deleting them. So my workflow is to empty trash (leaving locked files), briefly review the locked files, then delete those too.
I lock files which I don’t expect to alter in the future; I use a checksum routine to check the integrity of those files (although this function could, of course, be replaced by a tag).
I’d ask @Eve1873 to be a little careful with the term “we”; there is a stunning breadth of people using DEVONthink, and one person will not necessarily be doing what the other is. There have been numerous examples here in the forum of people requesting a feature be changed because it does not suit their personal use case (which is, of course, perfectly legitimate) only to find others relying on the feature just as it is.
On the other hand, thank you for suggesting an option; that provides everybody with the best of both worlds (allow locked files to be moved to trash yes/no); responses from DT in the past suggest they are a little worried the complexity of the software will increase too significantly if all the options users have requested were to be implemented.
Many users are already scared by the learning curve and versatility of DEVONthink. Now imagine having many more options (as a lot more than exist currently were requested so far).
I agree completely. They can’t be edited, but their place in the database can be disrupted so easily? It doesn’t make sense to me.
Thanks for considering this.
Since automatic sync happens very quickly, this undo feature is practically useless for accidental deletions that aren’t instantly noticed.
I agree; I think DEVONtech have gone a very clever way using hidden preferences; something the expert user can play with, and the new user is not confronted with.
There is obviously a logic to the behaviour @chrk is requesting - in general I would guess a new user would expect the locking function to lock a file in place. Doing so would, however, also lock the parents of the locked file, effectively causing inheritance from child to parent. It also opens other questions - if I remove the lock from a group, should its contents become unlocked? If a group is effectively locked because one file in it is locked, should it be marked locked? If so, then would the user expect the other contents also to be locked? Peoples’ interpretation of what is logical may well vary in regard to those questions; but the answers are not obviously less relevant (to me) than the behaviour of a single locked file. Rambling here, but just pointing out that a single decision taken with regard to complex software such as DT will seldom be as simple as it seems on first glance.
I agree that the logic of locked files is complex in general, but the timing of the locked item warning dialog (currently after trying to empty the trash) would just move to an earlier moment (to warn before actually moving to trash). The other details aren’t really affected by this unless I’m missing something.
My main issue is losing the locked item’s place in the database. Assuming I accidentally delete 1000 locked files from a smart view, I can practically restore the whole database from backups (unless caught instantly with an undo).
Thanks for the clarification and feedback. If implemented, what - for you - would be the logical behaviour of a smart rule or script attempting to move a locked file to trash? Would it fail with an error message for example, or succeed with the action?
Thanks Blanc.
In my (preferred) definition of locked items, the behavior would be the same for manual or automated processes, that is, the warning that happens after trying to empty the trash would just come earlier, before manual or smart rule deletions/moves are even possible. Smart rules would trigger that warning and skip locked items unless user confirmation is given, just like the empty trash warning currently does. I guess that’s another complex scenario, but an ideal solution in smart rules would give users a choice to skip/ignore, warn about or process locked items.
Thanks again for playing along with my thoughts. Current DEVONtech thinking is that smart rules should run without user intervention (Jim has commented on this a number of times in the past), so in your scenario the rule would have to fail (which, I would agree, would be logical); that’s perfectly manageable (because both rules and scripts can change the locking status).
If the behaviour did change, it might be worth giving users a heads-up (“as of the next release…”) - I for one would have a number of rules and scripts fail and would need to spend some time modifying them.
I love that users and DEVONtech can engage in this fashion here in the forum - this shows each taking the other seriously. Thanks
I appreciate your elaborate thoughts on this and got to admit that I myself haven’t thought about all possible consequences here. Since disruption of existing smart rules shouldn’t really be an option, I’ll adjust my ideal scenario from above to exclude automated areas like smart rules. After all, I could just add an item trigger to every smart rule to include marked > unlocked, to prevent automated processing of locked items.
I don’t see how options would deters users. And I would expect that many people who aren’t tinkerers never even look at the options and just use the defaults. Options that are deemed to be too technical could be put behind an “advanced” button I guess.
I just spent multiple days writing scripts, restoring backups, painstakingly comparing restored versions of my database from around a point in time now 4 months distant.
The reason for all this: I somehow, inadvertently, deleted what turned out to be 10 of my “locked” files that I had naively expected I had protected from myself. I have no recollection of doing this since these are buried deep in my group structure and are rarely, if ever, touched after creation until year’s end.
I noticed the problem recently, quite by chance, when I was looking at a sheet that I update with UUIDs for all of the locked files and there were 10 bad links. With help from @pete31 I now have a script for checking all those links and reporting any problems, i.e. deleted records.
This is in addition to something that had previously surprised me about locking files. That is that metadata (tags in my case) can be edited at will on a locked file.
I have read the comments above, and understand the conflicting requirements but I felt compelled to comment after losing faith in my system a little bit over the past few days.
In the meantime, I will rely on my sheets of links and test scripts as well as add smart groups to monitor the trash for files that are important to me and shouldn’t be deleted ordinarily.
