problem renaming/deleting files on other 'volumes' (OSX)
tsj at unimelb.edu.au
Wed Mar 9 21:38:26 CST 2005
It seems that if I ignore the rev 'rename' and 'delete' commands and go
with the following shell commands - 'ditto' to copy and 'rm' to delete
then the file is (effectively) renamed. Using 'mv' from the terminal
doesn't work - which probably explains why Rev's 'rename' fails. Any
Hi Frank - this shouldn't be a problem as, according to a 'get info' on
the affected files and folders I'm the owner and have read and write
access. Having said that, I'm sometimes able to get rename working if I
set the permissions for all users to read and write - but as I said,
that's only sometimes.
I've just checked and I've checked 'ignore ownership' on the entire
volume. I'm at a bit of a loss.
> Do you also have write permission to the directory *containing* the
> file(s) and/or folder(s) you are trying to rename and/or delete?
> Even if you are the owner of the containing directory, make sure you
> have write permission (if you are the owner you can give this to
> yourself), since you need that in order to rename/delete contained
> Think of it this way (UNIX, and thus OS X, does):
> Since the 'directory' is essentially a 'list' of files and file
> equivalents (directories, named pipes, "special files" representing
> devices, etc.), the contained items are separate entities, but the
> *name* of the item is stored in the directory itself, meaning that to
> change the name you must be able to change the directory.
> In UNIX (and thus in OS X if using a UFS file system, the permissions
> work the same if using HFS), it is possible for one file to be pointed
> to by multiple directory entries; each directory entry pointing to the
> file is called a "hard link," and the file maintains a count of how
> many hard links point to it. The file is deleted when that count
> reaches zero. So to delete a file, you delete the directory entry
> pointing to it, which means modifying the directory.
More information about the use-livecode