Nimble Commander forum

Files that have the locked (uchange) flag set can't be deleted. This is different from insufficient user access permissions, this is a flag set in File Info dialog ("locked" tickbox) or via the chflags uchg terminal command and requires user access permission to be able to set or reset in the first place.

Current behaviour: Failed to move an item to Trash. Error: The file couldn't be saved because you don't have permission. Retry/Skip/Delete Permanently/Abort. Retry or delete obviously does nothing.
Error message is confusing, it says "couldn't be saved because you don't have permission" but issue is not permissions, it's flags.

Expected behaviour:
1. Note that file is locked
2. Warn user - Skip/Skip all/Overwrite (all) or Delete (all) anyway/Abort, just like when overwriting any normal existing file.

Same as with Read Only file attributes on FAT filesystems. User should be always able to override any Read Only flags on files he has access permissions to, whatever the filesystem, unlike not having permissions (since flags are below access permissions and user already has access/R/W permissions to the file in order to set the flag in the first place).

Hi, thanks for the feedback.
Can you provide a bit of a context, e.g. where these locked files are coming from in your case?
While generally agreeing that NC should be able to handle such situation, I want to understand a bigger picture regarding the use-case.

Hello! Thanks for the reply. Various context of file operations and file sources, I'll list a few examples. I am of course only talking about the Read-only (FAT/FAT32/exFAT) and User Immutable (uf_immutable, uchg) flags only, not the system file flags or access permissions.

• Normal user operations. The Locked checkbox in Finder (and the corresponding uchg flag) is used similar to Read-only file attribute under Windows, to prevent an accidental deletion or overwrite of an important file by the user, without potentially messing up permissions. People use them in Finder on important documents as unlike permissions, the uchg flag is easily accessible from Finder "Get info" window, inherently more understandable to laic users than permissions and the user has less chance to mess up. I come up upon user locked documents somewhat often when supporting users (and cleaning up some file storage mess). It's even encouraged by Apple as per this document, you can Lock a text file right from the document title when editing it.
• Moving mixed locked and unlocked files - as above, but I have a bunch of mixed Locked and normal files that I need to organise or move to different folder, but keep the Locked attribute of those that have it. Now, it's Copy, keep them selected, Attributes, clear uf_immutable, Delete. Bit of a fringe case, but sometimes useful (Finder allows only copy, but file managers are not Finder).
• Cross-OS disks (exFAT, FAT32,...) where some files have a Read-only attribute set in Windows, for whatever user reasons (possibly same as above). I read Windows disks on Mac as well.
• Digital cameras (especially professional ones) have a Lock button or function to tag important photos in-camera (usually by setting Read-only file attribute, for nearly three decades). These cameras use FAT32 storage, the FAT32 RO attribute gets read as uchg by Mac OS and presents the same problems. With a thousand photos from one football game or wedding and tens or more are set as RO, there could be thousands of locked files later to deal with later, accumulated on temporary or backup disks, et cetera (normally, pro photo software deals with it during photo ingest, but not when copying by Finder or file managers.

Currently, trying to delete a locked file in NC gives an error (vague one, although if the system call doesn't give you the exact reason it failed, I can well understand the vagueness!).

Deleting them is a multi-step process with:

1. Realising from the error message that a file has "user immutable" (locked) flag or RO file attribute set (on FAT/others)
2. File Attributes
3. clicking User flags/Immutable one or two times (if multiple files selected)
4. deleting again

Here is how other file manages deals with it:

• Finder itself treats the flag as user would expect. Warning upon trying to delete, but allowing you to override the flag and delete anyway, with a helpful message:
  Item “example.jpg” is locked. Do you want to move it to the Trash anyway? (Apply to All) / Skip / Stop / Continue
  This is IMHO the correct way. Most Windows OFMs work the same way, if I can remember correctly (it's been a while), and it's Apple's own behaviour. It's different behaviour from trying to delete a file you don't have write permissions for, as should be expected.
• MuCommander fails, after a long wait, with the obscure "One or more files could not be moved to the trash" message. MuCommander has no provision to change or even view (sic!) file attributes (even though it says it's cross platform).
• CommanderOne fails with an obscure "Couldn't delete "example.jpg", error: “example.jpg” couldn’t be removed because you don’t have permission to access it". While CO can show and edit both permissions and attributes (flags), it does so only for a single file (sic!), as far as I know.
• Total Commander - apparently has user option what to do (Get Confirmation - overwrite/delete read only files)
• Far Manager and Dos Navigator (the venerable classics!) - if I can remember corretly (it's been a very long time!), they let you override RO attribute during deletion (asking for confirmation), just like Finder does.

I am suggesting an approach (perhaps not the default, but set in preferences) like Finder would be the best, if only for the User Immutable - "Locked" flag. Delete with additional confirmation. System flags require sudo anyway and might be dangerous to delete even in Admin mode with just a single confirmation...


It's a bit of a strange mix of different and legacy systems. File attributes sometimes supersede permissions. Sometimes not, it's a bit of a mess. But the User Immutable flag (or Read-only file attribute) is used in the same way on both Mac and Windows, as an easy way to protect a document, without having to delve into user permissions.

Thanks!

Thank you for the fantastic explanation!
I didn't realise how easy it is to stumble upon such DOS-style "read-only" files nowadays.
Will fix the issue, hopefully next preview build will behave correctly.

Awesome, thanks!

Fixed: viewtopic.php?f=7&t=578
UPD:
(duh, literally after posting this I realised that overwriting locked items is not handled yet)