root can't delete locked files
- Thread starter theed
- Start date
OK, so in defense of my prior POSIX statement, Apple's website says even now ...
Mac OS X Is Unix-Savvy
Mac OS X supports POSIX file system semantics and NFS file sharing, as well as standard services like telnet and FTP, allowing easy operability with UNIX systems and applications.
Also, trash seems to accumulate in a variety of places:
/.Trashes/<uid>/
/Volumes/*/.Trashes/<uid>/
~/.Trash
When emptying the trash works, that's cool. But chasing these down from the command line seems less than satisfactory. I'm considering writing a script, something like trashdump which requires root to run it effectively, and unlocks and removes all of the files in these paths.
Would anyone be interested in this command line solution to the permafull trash can?
Mac OS X Is Unix-Savvy
Mac OS X supports POSIX file system semantics and NFS file sharing, as well as standard services like telnet and FTP, allowing easy operability with UNIX systems and applications.
Also, trash seems to accumulate in a variety of places:
/.Trashes/<uid>/
/Volumes/*/.Trashes/<uid>/
~/.Trash
When emptying the trash works, that's cool. But chasing these down from the command line seems less than satisfactory. I'm considering writing a script, something like trashdump which requires root to run it effectively, and unlocks and removes all of the files in these paths.
Would anyone be interested in this command line solution to the permafull trash can?
strobe
Puny Member
DUH there are several trash directories.
You can't move a file into a single trash if it's on another volume.
Although I have to wonder why Apple chose to use a new trash called .Trash instead of using the old MacOS 9 Trash. They are both hidden, so why use a new name? Makes no sense.
Oh well too late to reverse that dumb move.
You can't move a file into a single trash if it's on another volume.
Although I have to wonder why Apple chose to use a new trash called .Trash instead of using the old MacOS 9 Trash. They are both hidden, so why use a new name? Makes no sense.
Oh well too late to reverse that dumb move.
rharder
Do not read this sign.
Gotta agree with Strobe: a locked file is locked for a reason, that reason being that it's hard to delete the file.
That said, an OS with a User Friendly claim ought to offer <em>some way</em> to delete files that are locked without manually unlocking each individual file. Other OS's (is it 9 or Windows?) asks for confirmation before deleting locked files. That's nice.
In the meantime, from a prompt you can type
<pre style="font-size:larger"> chflags nouchg mylockedfile</pre>
to unlock a file.
-Rob
That said, an OS with a User Friendly claim ought to offer <em>some way</em> to delete files that are locked without manually unlocking each individual file. Other OS's (is it 9 or Windows?) asks for confirmation before deleting locked files. That's nice.
In the meantime, from a prompt you can type
<pre style="font-size:larger"> chflags nouchg mylockedfile</pre>
to unlock a file.
-Rob
option emptying of trash has no effect, and that's a stupid keystroke anyway.
Moving a locked file to the trash is not allowed, but moving a folder with a locked file to the trash is.
when attempting to move a locked file or empty the trash of a locked file you are simply told that you do not have permissions. This isn't correct, you do have permissions, the file is locked.
when emptying the trash with a locked file, the trash doesn't empty itself as far as possible on its own, it comes up with monologue boxes like Windows OS and if you don't continue through that file, other easily deleted files are never touched.
My analysis is that the trash is simply not done yet, and I refuse to debate the matter further until I see what would seem to be a final product in terms of how the OS handles trash.
If the trash remains at all the same in the next (ever just around the corner) update, then I'll yell my friggin head off 'casue it's all wrong. Until then, I'm ignoring it.
Moving a locked file to the trash is not allowed, but moving a folder with a locked file to the trash is.
when attempting to move a locked file or empty the trash of a locked file you are simply told that you do not have permissions. This isn't correct, you do have permissions, the file is locked.
when emptying the trash with a locked file, the trash doesn't empty itself as far as possible on its own, it comes up with monologue boxes like Windows OS and if you don't continue through that file, other easily deleted files are never touched.
My analysis is that the trash is simply not done yet, and I refuse to debate the matter further until I see what would seem to be a final product in terms of how the OS handles trash.
If the trash remains at all the same in the next (ever just around the corner) update, then I'll yell my friggin head off 'casue it's all wrong. Until then, I'm ignoring it.
Yes, you are right about that dialog box thing. In my case there are _many_ locked files in _many_ levels of folders. I stopped counting the dialog boxes after sixty. I can't believe that Apple would allow this to go on for long. It is too easy a trap for average Joe user to fall into, and if you regularly want to delete large files then your hard-drive can start to fill up quite quickly. Even if a CLI solution is available, I would hesitate at this point. I can see the importance of learning UNIX, and I have begun, but I am not confidant enough in those skills yet to want to start deleting mass amounts of locked files. And what about most Mac users who have never touched a command line and don't even want to try? Are they to be eternally stuck with 9.1? No doubt Apple will fix this, but when? I guess we just wait for OS X.1 or whatever...
rm -f does not work
I also think this is odd. Even more disturbing is the fact, that rm does not behave unix like but tar does. Using tar one seems to loose the resource forks. Such an asymmetry should be regarded as a bug. Either the behaviour is unix like or osx like.
Anyhow, there should be a unix command to get rid of _any_ file, regardless of any flags. Be it rm -f or some osx equivalent.
I also think this is odd. Even more disturbing is the fact, that rm does not behave unix like but tar does. Using tar one seems to loose the resource forks. Such an asymmetry should be regarded as a bug. Either the behaviour is unix like or osx like.
Anyhow, there should be a unix command to get rid of _any_ file, regardless of any flags. Be it rm -f or some osx equivalent.
I didn't know about chflags - useful to know - thanks whoever posted that.
Another way is to use a tool from the developer CD
/Developer/Tools/SetFile -a l lockedfile
will remove the lock attribute from lockedfile (that's a lowercase 'ell' after the -a
There is a companion GetFileInfo command in there too.
SetFile also lets you change, among other things, creator, hidden flag and stationary flag.
Another way is to use a tool from the developer CD
/Developer/Tools/SetFile -a l lockedfile
will remove the lock attribute from lockedfile (that's a lowercase 'ell' after the -a
There is a companion GetFileInfo command in there too.
SetFile also lets you change, among other things, creator, hidden flag and stationary flag.
Despite what everyone on this board seems to think you can easily unlock multiple files at a time by using * in conjunction with the chflags command mentioned previously.
ie. "sudo chflags nouchg *" will unlock every file in a given directory. I imagine there is a recursive way to do this with folders as well.
Everyone who keeps saying to use the option key while emptying the trash seems to be forgetting that we are discussing OS X here, not OS 9. This method doesn't work with multiple user systems on OS X.
ie. "sudo chflags nouchg *" will unlock every file in a given directory. I imagine there is a recursive way to do this with folders as well.
Everyone who keeps saying to use the option key while emptying the trash seems to be forgetting that we are discussing OS X here, not OS 9. This method doesn't work with multiple user systems on OS X.
in celebration of the cyclical nature of this thread, I thought I'd re-post what got this started before declaring the thread dead. If you write anything else here, you haven't read the thread. ... except for endian. 
- 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?
- 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?
