root can't delete locked files

T

theed

Registered
This is about the most annoying thing I've found in X. create a file, click the lock attribute. Then root can't delete it ar change it's permissions. I have a lot of files that I have to boot back into 9 to get rid of. One big culprit of locking files is DreamWeaver.

Anyone know if this philosophy has changed? Anyone know how I can kill these files short of becomeing the user and clicking unlock on each and every file?
 
Does that worked even to delete locked files of a different user? While handy, it also worries me a bit.

Also, the fact that root cannot delete some files is a bit annoying... could someone who knows the CLI tell me if rm works on locked files? (I'd do it, but I no longer have PB installed.) I think that it should... and at least that's a start. Then someone could write a GUI frontend that you could run as root with pseudo.

Zach
 
Unfortunately it doesn't seem to--implausible as it seems, neither as owner or root can I delete a locked file from the CLI.
<code>
% sudo rm unicode\ monstrosity.rtf
override rw-r--r-- ben/staff for unicode monstrosity.rtf? y
rm: unicode monstrosity.rtf: Operation not permitted
</code>

Same result for rm -f, of course.

Why on Earth would they do such a thing?
 
For the same reason root can't delete files on a locked floppy.

Don't act like this is a new concept.
 
On a locked floppy, the little slider is supposed to prevent writes via some hardware mechanism. This does not apply to individual locked files on a hard drive at all. Locking something in software so that even root can't get to it strikes me as relatively new.

Zach
 
new is one word for it

stupid is another

I like the concept of locking files on a single user system, but on a multiuser system, the lock attribute should only be effective to regular users, if effective at all. It seems like a leftover from single-user UI.

Lock's only use is to protect your own files from you, everything else should be done through unix style permissions. (although not necessarily from the command line) If you're not the owner, you should ignore the lock attribute altogether.
 
Just ask for a command to unlock a file you own, geez.

It's like anything which wasn't invented 30 years ago treads on sacred land to you eunuchs people.

And it IS the same hting as a locked floppy. The purpose of a locked floppy is to prevent deletion, the purpose of a locked file is the same. The fact that one is done via hardware and the other software is irrelevant. In fact the floppy lock isn't done in hardware at all, it's only a bit of information the floppy driver can choose to ignore.
 
Strobe, I love you like a brother, so don't take it too hard when I say - you're wrong.

There's an important distinction between hardware and software, anyone can unlock that floppy, therefore the floppy lives in a single user kind of reality, everyone who touches it is it's owner. Files are not so much the same, and the issue I'm having is because I live in a massively multi-user universe, and I'm controlling a machine that other people avidly use. Here's the problem:

Dave no longer uses my machine, so, no big deal, I'll just throw his stuff away. My user account doesn't have permissions to throw away his stuff. If it were a floppy it'd already be gone. So I pop over into the god account for the machine and I should be able to clear that up right? After all, I own this machine! Nope, not even as root can I get rid of his files. This is a gross violation of standards if I were to try to run scripts and expect them to work or anything to that effect. Without knowing Dave's password, there's no reasonable way for me to delete his now abandoned files!

I don't know Dave's password, nor do I ever want to, so it is essential that if I can be root, that I can do things. As it is right now, I wouldn't have permissions to unlock the file even if there were a command. It's a new, confusing, and counterproductive addition to an already complex permissions set. And as it is now, it's a show-stopping productivity halting gaffe in CLUI. ... and how dare you acuse me of being of unix descent. I'm a mac user who was taught to program on Suns. so there :p
 
Root can unlock files, but only in the GUI, and a mechanism that that requires your physical presence at the machine to delete files does not measure up. I don't expect ever to have this problem (sysadminning is not what I do), but if I ever type "<code>sudo rm -rf ~dumbass/huge_directory/</code>" I expect it to remove that directory, and not give me any guff. A command-line unlock utility would help, but it's still a stupid workaround.

Is there any reason that the "Lock file" mechanism can't be adequately replaced within the framework of standard Unix file permissions anyway? I don't know of any use for it other than write and trashing protection, and <code>chmod -w</code> will do that nicely--just map the file inspector checkbox to do that. Get rid of "can't delete some items because they were locked" and replace with "are you sure you want to delete write-protected files X Y and Z?" Same functionality for GUI users, doesn't break the CLI for the sysadmin.
 
One problem with that is the OS would have to be conscious when transferring a file to and from a MacOS client, and I don't see an easy method of doing that.

If you're not using OS X as a single user (which 99.99% of mac users will because shell access is totally insecure unless everybody can be trusted with root) then why not just use UFS which lacks the lock flag?

I will ask the Darwin dev list whether the lock bit gets converted to a write flag when transferring a file from HFS+ to UFS and vice versa. It's not used often.
 
According to Matt Watson at Apple:

The lock indicates the immutable bit is set. It has nothing to do with the write permission on the file.

man chflags

matt.

 
"just map the file inspector checkbox to do that. "

the problem with that is what if you goto that file on OS 9. They should just make OS X treat any lock bit as a no write permission for non-root users. I consider not being able to delete locked files as root a bug in OS X and no more.

peter
 
Not having MacOS X in front of me, maybe someone could confirm whether the following solves the problem:

rm -f myfile

Its a command line solution that works on most Unix platforms, so maybe on MacOS X?
 
rm -f differs from rm only in it's amount of complaining, not in the amount of deleting. But alas, no lovin'.

from the command line, no one can delete a locked file or unlock it.
even root.
even the owner.

If Apple was trying to be at all Posix compliant like they said, this is simply a bug.
 
Similar problem, but in my case I have a huge Folder with lots of locked files all in different levels of the hierarchy. Even with access as that user, what a pain to spend Hours unlocking every one. Just trashing with the option key doesn't work because supposedly I don't have the permissions. And as root It's not in the trash. If I su to root and try then I get:

% sudo rm unicode\ monstrosity.rtf
override rw-r--r-- ben/staff for unicode monstrosity.rtf? y
rm: unicode monstrosity.rtf: Operation not permitted

this type of thing posted by benW earlier. This is frustrating because every time i Go to empty the trash of minor stuff, I get it counting out 1500 or so items from this bloated folder and then telling me it can't even do it after all that.

There seems to be no way to trash this thing! Even if I pull it out of the trash, all it does is copy the folder to the desktop, multiplying the problem.
 
I sent in feedback to apple asking for a command line utility for locking and unlocking files. I said it should be called lk or lkf and have -l and -u as options for lock and unlock. If you like this idea submit it as feedback as well. The more feedback the more likely they are to do it.
 
Originally posted by VGZ
I sent in feedback to apple asking for a command line utility for locking and unlocking files. I said it should be called lk or lkf and have -l and -u as options for lock and unlock. If you like this idea submit it as feedback as well. The more feedback the more likely they are to do it.
Click to expand...

As alluded to earlier in the thread, the command
line way of using this is the 'chflags' command.
Deleting a locked file from the shell (as owner
of the file or as root) happens like this:

[samantha:~] dwalker% chflags nouchg driverlist.txt
[samantha:~] dwalker% rm driverlist.txt

See 'man chflags' for more info.
 
You must log in or register to reply here.
Back
Top