Based on lot of research below is what I have come up with
find /Some_Dir -type f -mtime +30 -delete -printf "%TD %p\n" >> /Logfile.txt 2>&1
This is doing a good job of deleting the files and it also deletes files with spaces. One concern I have is that this is deleting the files which is just ready only or even files with 000 permission. Is that expected result?
Yes. You are not modifying the files, you are modifying the containing directory.
To forbid deletion of files, you need to either deny write access to the directory, or set the sticky bit (more accurately but less mnemonically known as the "restricted deletion flag") on the directory and ensure the user trying to delete the file does not own the file or the directory. World-writable directories like /tmp will generally have the sticky bit already turned on.
If you just want to change the behavior of the find command, use -writable or -perm.
Related
I recently attempted to move some files by running an -exec mv command with find (command linked below). When I did this, I mistyped the destination directory path (so the directory did not yet exist) and mv created what appears to be an executable instead of a directory?
When I run "Get Info" one image renders and the file size is about the correct size for an image, but hundreds of files were supposed to be copied. Have I lost this data for good? Is there any way to get macOS to recognize this "executable" as a directory?
This is the command I used:
find . -type f -name "*.JPG" -exec mv {} ../../DestinationFolderName \;
Here's an image showing a successful mv into an existing directory, and what happened when I put a path to a directory that did not yet exist.
Unfortunately "mv" to a name that doesn't exist is interpreted as a filename rather than a directory. So the OS has, one-by-one, copied your JPG file on top of each other. The resulting file is most likely whatever JPG happened to be the one it moved last (if you rename it to JPG extension you can check which one).
So, very unfortunately, you probably need to investigate a data recovery tool for MacOS quickly (and do so before you've done things that make more files on your disk, as much a possible). The "ghosts" of the files are for now at least mostly still present on your hard drive (as deallocated segments), but are back in the pool to be overwritten as you create new files (even when your browser creates temporary cache files, and things like that). It's a conundrum.
If you don't have a backup/time-machine of the files, the best thing to do is get a MacOS data recovery program QUICKLY.
VERY sorry not to have a happier answer.
I am new to perforce and unix. While doing a 'p4 sync' was getting an error "can't clobber writable files" for some of my files.
I then did a "chmod -R 555 ./*" , thinking that it would remove the write permissions for the files that were giving me the above mentioned error. I didn't know that we have different permissions for directories and files in perforce. So now I have set r-x permissions for all directories and files, and now when I try to do a 'p4 sync' I am getting the following kind of error for all the files:
open for write: /home/path_to_file/tmp.18455.196170: Permission denied
What should I do to revert back the original permissions that perforce provides?
An easy way to apply different permissions to files vs directories is to use find, like so:
find . -type d -print0 | xargs -0 chmod 755
find . -type f -print0 | xargs -0 chmod 444
This would apply permissions 755to directories and 444to files.
However, please note I don't know which permissions you have to apply in your case, you may want to look at another installation to get an idea. In your case I suspect the error message comes from the directories missing write permissions.
Also note that using an octal mask with chmod is not necessarily what you want, as it means "assign these permissions"; when you want to "remove" or "add", it's usually better to use a symbolic mode; for example, to remove all three write bits on files only, you would specify a-w(remove w to all fields):
find . -type f -print0 | xargs -0 chmod a-w
Finally, note that you can use find to recursively list permissions of all files and directories, for manual verification:
find . -ls
The error indicates that files in the workspace are writable, but have not been checked out by 'Perforce' (opened for edit).
If you want writable files to be overwritten by files you sync from Perforce, set the 'noclobber' option to 'clobber' in the client spec.
More information about this option and the 'p4 client' command is available here:
http://www.perforce.com/perforce/r15.1/manuals/cmdref/p4_client.html#p4_client.usage
Hope this helps,
Jen.
So this doesn't seem like a terribly complicated question I have, but it's one I can't find the answer to. I'm confused about what the -p option does in Unix. I used it for a lab assignment while creating a subdirectory and then another subdirectory within that one. It looked like this:
mkdir -p cmps012m/lab1
This is in a private directory with normal rights (rlidwka). Oh, and would someone mind giving a little explanation of what rlidwka means? I'm not a total noob to Unix, but I'm not really familiar with what this means. Hopefully that's not too vague of a question.
The man pages is the best source of information you can find... and is at your fingertips: man mkdir yields this about -p switch:
-p, --parents
no error if existing, make parent directories as needed
Use case example: Assume I want to create directories hello/goodbye but none exist:
$mkdir hello/goodbye
mkdir:cannot create directory 'hello/goodbye': No such file or directory
$mkdir -p hello/goodbye
$
-p created both, hello and goodbye
This means that the command will create all the directories necessaries to fulfill your request, not returning any error in case that directory exists.
About rlidwka, Google has a very good memory for acronyms :). My search returned this for example: http://www.cs.cmu.edu/~help/afs/afs_acls.html
Directory permissions
l (lookup)
Allows one to list the contents of a directory. It does not allow the reading of files.
i (insert)
Allows one to create new files in a directory or copy new files to a directory.
d (delete)
Allows one to remove files and sub-directories from a directory.
a (administer)
Allows one to change a directory's ACL. The owner of a directory can always change the ACL of a directory that s/he owns, along with the ACLs of any subdirectories in that directory.
File permissions
r (read)
Allows one to read the contents of file in the directory.
w (write)
Allows one to modify the contents of files in a directory and use chmod on them.
k (lock)
Allows programs to lock files in a directory.
Hence rlidwka means: All permissions on.
It's worth mentioning, as #KeithThompson pointed out in the comments, that not all Unix systems support ACL. So probably the rlidwka concept doesn't apply here.
-p|--parent will be used if you are trying to create a directory with top-down approach. That will create the parent directory then child and so on iff none exists.
-p, --parents
no error if existing, make parent directories as needed
About rlidwka it means giving full or administrative access. Found it here https://itservices.stanford.edu/service/afs/intro/permissions/unix.
mkdir [-switch] foldername
-p is a switch, which is optional. It will create a subfolder and a parent folder as well, even if parent folder doesn't exist.
From the man page:
-p, --parents no error if existing, make parent directories as needed
Example:
mkdir -p storage/framework/{sessions,views,cache}
This will create subfolder sessions,views,cache inside framework folder irrespective of whether 'framework' was available earlier or not.
PATH: Answered long ago, however, it maybe more helpful to think of -p as "Path" (easier to remember), as in this causes mkdir to create every part of the path that isn't already there.
mkdir -p /usr/bin/comm/diff/er/fence
if /usr/bin/comm already exists, it acts like:
mkdir /usr/bin/comm/diff
mkdir /usr/bin/comm/diff/er
mkdir /usr/bin/comm/diff/er/fence
As you can see, it saves you a bit of typing, and thinking, since you don't have to figure out what's already there and what isn't.
Note that -p is an argument to the mkdir command specifically, not the whole of Unix. Every command can have whatever arguments it needs.
In this case it means "parents", meaning mkdir will create a directory and any parents that don't already exist.
On my Linux system, I've got into a situation where there are not write/execute permissions on directories on a mounted drive. As a result, I can't get into a directory before I open its permissions up. This happens every time I mount that drive. The mounting operation is done by a tool under its hood, so I doubt if could modify mount parameters to address this problem.
As a workaround, I am using this find command to modify permissions on directories. I use it repetitively, since it gets one more level of directories on each run.
find . -type d -print0 | xargs -0 -n 1 chmod a+wrx
I am sure there is a better way to do this. I wonder if there is a find option that processes a directory first and then its contents - the opposite of -depth|-d option.
Any tips?
Try:
chmod +wrx /path/to/mounted/drive/*
Another possibility is to investigate the mount options available for that particular file type (I'm guessing FAT/VFAT here, but it might be something else). Some file systems have mount options for overriding default permissions in some form or other... That would also avoid having to change all the permissions, which might have some effect when you put that file system back to whereever its original source is (is this a memory card from a camera or something or a USB stick, or .... ?)
Thanks to StarNamer at unix.stackexchange.com, here's something that worked great:
Try:
find . -type d -exec chmod a+rwx {} ';'
This will cause find to execute the chmod before it tries to read the directory rather than trying to generate a list and feed it to xargs.
From: https://unix.stackexchange.com/q/45907/22323
I would like to see all the files recursively in a directory or drive which are not read only.
I would like to do this as i am using the clear case and i would like to check on on the files which are to be added to he source control or view-private files.
even a clear case command would help thanks. For clear case specific i tried "ls -vob_only" command but not helped or i failed to use it so felt that using UNIX command might help.
find . -type f -perm -o=r
find . -type f -perm
for more information check the man page for -perm options.
A committed file in ClearCase is indeed read-only.
If by "not read only" you refer to private files not yet added to a view, you can start by looking for private files, based on grep rules on a recursive ls
cleartool ls -r -nxn
That would be safer than the "read only" criteria, since private files can also be read only (even though they are "not checked-in" yet, not yet managed by ClearCase)
The idea behind a recursive ls is to display all the rules associated with all the files of your view.
No rule means "private" (whether the file is read-only or not)
Rule: ...\aBranch\LATEST means it is committed (and -- incidentally -- read-only)
Rule: CHECKEDOUT means it is committed, but being modified (read-write, but nothing prevents the user to make it read-only again without checking it in)
Rule: hijacked/eclipsed: committed, but modified without having being checked-out yet (read-write, but again, can be turned read-only without notifying ClearCase)
So you can grep whatever set of files you actually need from that list, based on ClearCase rules (or lack thereof).