shell script to create backup file when creating new file in particular directory - linux

Recently I was asked the following question in an interview.
Suppose I try to create a new file named myfile.txt in the /home/pavan directory.
It should automatically create myfileCopy.txt in the same directory.
A.txt then it automatically creates ACopy.txt,
B.txt then BCopy.txt in the same directory.
How can this be done using a script? I may know that this script should run in crontab.
Please don't use inotify-tools.

Can you explain why you want to do?
Tools like VIM can create a backup copy of a file you're working on automatically. Other tools like Dropbox (which works on Linux, Windows, and Mac) can version files, so it backs up all the copies of the file for the last 30 days.
You could do something by creating aliases to the tools you use for creating these file. You edit a file with the tools you tend to use, and the alias could create a copy before invoking a tool.
Otherwise, your choice is to use crontab to occasionally make backups.
Addendum
let me explain suppose i have directory /home/pavan now i create the file myfile.txt in that directory , immediately now i should automatically generate myfileCopy.txt file in the same folder
paven
There's no easy user tool that could do that. In fact, the way you stated it, it's not clear exactly what you want to do and why. Backups are done for two reasons:
To save an older version of the file in case I need to undo recent changes. In your scenario, I'm simply saving a new unchanged file.
To save a file in case of disaster. I want that file to be located elsewhere: On a different computer, maybe in a different physical location, or at least not on the same disk drive as my current file. In your case, you're making the backup in the same directory.
Tools like VIM can be set to automatically backup a file you're editing. This satisfy reason #1 stated above: To get back an older revision of the file. EMACs could create an infinite series of backups.
Tools like Dropbox create a backup of your file in a different location across the aether. This satisfies reason #2 which will keep the file incase of a disaster. Dropbox also versions files you save which also is reason #1.
Version control tools can also do both, if I remember to commit my changes. They store all changes in my file (reason #1) and can store this on a server in a remote location (reason #2).
I was thinking of crontab, but what would I backup? Backup any file that had been modified (reason #1), but that doesn't make too much sense if I'm storing it in the same directory. All I would have are duplicate copies of files. It would make sense to backup the previous version, but how would I get a simple crontab to know this? Do you want to keep the older version of a file, or only the original copy?
The only real way to do this is at the system level with tools that layer over the disk IO calls. For example, at one location, we used Netapps to create a $HOME/.snapshot directory that contained the way your directory looked every minute for an hour, every hour for a day, and every day for a month. If someone deleted a file or messed it up, there was a good chance that the version of the file exists somewhere in the $HOME/.snapshot directory.
On my Mac, I use a combination of Time Machine - which backs up the entire drive every hour, and gives me a snapshot of my drive that stretches back over a year and a half) and Dropbox which keeps my files stored in the main Dropbox server somewhere. I've been saved many times by that combination.
I now understand that this was an interview question. I'm not sure what was the position. Did the questioner want you to come up with a system wide way of implementing this, like a network tech position, or was this one of those brain leaks that someone comes up with at the spur of the moment when they interview someone, but were too drunk the night before to go over what they should really ask the applicant?
Did they want a whole discussion on what backups are for, and why backing up a file immediately upon creation in the same directory is a stupid idea non-optimal solution, or were they attempting to solve an issue that came up, but aren't technical enough to understand the real issue?

Related

Check if file has been changed and which line in file

I am looking some solutions which help me to track any changes which have been made on files. I am working on Linux system where a lot of people have access to the same files. Sometimes it is happened, that someone changed something in file and don't notify other users. So I would like to write some script to check if provide file path or files have been changed, if so then write in file let's say "controlfile_File1.txt" something like that "File changed %date, line XXX". I know that I can use md5checksum for that, but I will get only info if file changed but I would like to know which line is changed. I also think about solution to make copy of this file to some place and make some diff between copied file and current file?
Any ideas?
thanks for support.
Your question goes above the possibilities of Linux as a platform: Linux can show you the last modification date of a file, and the last time a file has been accessed (even without modifying the file), but that's it.
What are you are looking for, as already mentioned in the comments, is a version control system. As mentioned indeed, Git is one of them, but there are also others (SourceTree, SourceSafe, Clearcase, ...) each of them having their (dis)advantages.
One thing they all have in common is that modifying such a file does not go that simply anymore: at every time somebody has modified such a file (a file under the version control system), (s)he will be asked why (s)he has done this, this will also be recorded for later reference.

P4V not seeing new submits after OS recovery

I've googled this, and saw that someone had a similar problem here -> stackoverflow, but as luck would have it, unresolved.
I have an issue where my P4 client is not able to see or access any submitted files that are newer than 4 months old.
Background - My root directory/db files are on D drive which is undisturbed. I got a nasty virus yesterday, so I checked in all my workspace stuff and recovered to a December drive of my OS. Now that I've successfully booted up in my December version of my OS (where the same version P4V and P4A is already installed), my P4V is only able to see and access files up to 12/15/2015 - nothing after. The drive image I recovered from is dated 12/19/2016. Yet, I can physically inspect all my post Dec P4 checkins in the physical location of my DB on D drive. It's ALL THERE.
Here's really interesting info - out of curiosity, I recovered back to my Virus laden OS from yesterday. Opened up P4V, and it is able to see and access all my files up till my very last submitted file which was checked in yesterday.
Other important into
- The depot, stream, and workspace that my p4 is using is the same between my recovered Dec recovery OS, and yesterday's Virus laden OS. Nothing was ever changed in my P4 settings.
System info:
Windows 10
P4V and P4A - NTX64/2014.3/1007540 (for both my recovered windows image from Dec, and yesterday's virus laden windows)
P4 is my achilless heel. Help appreciated. I will not take offense if you explain things to me like a 3rd grader.
Cheers,
Paul
First off, I used incorrect terminology in my original question. I had my depots on D drive and everything else in their default locations on C.
Where I had it wrong: in the belief that as long as I had my depot files backed up to a safe location, I was protected. There is more to it than that :|
What went wrong: When my PC crashed, I recovered to a 5 month earlier December version of my Windows install which means (obviously) I have December's install of P4 with database files only aware of files I checked in up to December. I did indeed have 1000s of files check in after Dec, all alive and intact, but P4 is simply unaware of it. An assumption (which I had) that P4 simply peeks into the Depots to stay up to date of their contents is an incorrect and dangerous one.
To those who may benefit: For those do-it-yourselfers, these are the 2 things in Perforce you should be backing up if you want to be able to do a full recovery later down the line when things go bad:
Database files. By default, they live in the Perforce application’s “server” directory. For me, there are 67 database files in my C:\Program Files\Perforce\Server. They are all prefixed with db.* and it’s these files that P4 uses to “know” the current state of things, like, your changlists, checked-out files, all your workspaces and their settings, depots and their settings, etc, etc etc. Oh, and what files you even have in your depot! Unfortunately, when backing up database files, you can’t just copy/paste them, but must use command line commands to properly generate 2 other file types (journal, checkpoint) specifically for recovery purposes. It is these files that you'll generate new database files from in a recovery operation.
Depot directories. Depots specify directory trees that your files get stored to, and checked out from when working in your workspace. Files stored here won’t be in their native format, and non-binary files will have their contents tweaked on top of that. Depot directory trees can be manually copied/paste to a backup location.
Proper backup/recovery information can be found here. Like many things, it’s simple once you understand it, but reading this is a bit of a mouth full. It would have helped me to just see slightly fleshed out sample commands along with the reading material, so I’ve included some here. These are the bare minimum command line commands (plus other manual stuff), and will recover a checkpoint, not checkpoint + journal (again, take a look at the link to get a better understanding). Also, I would recommend practicing backup/recovery in a safe throw away environment (or throw away assets) to get the hang of this before doing it for real.
---------- Backup ------------
Despite all the material in the link, it only takes a bare minimum of 3 command line commands (plus other non-command stuff) to do a proper P4 backup, and 1 cmd (among other things) to recover on my end. Again this is only a partially fleshed out sample to illustrate what the command prompt portion of backup/recovery looks like. There is a little more to it than simply running these to get you where you want.
(note: On Windows, you may need to start a windows command prompt as administrator)
>p4 set P4USER=superuser_name
>p4 -q verify //...
>p4d -r "C:\Program Files\Perforce\Server" -jc <yourBackupDirectory>\<prefixOfYourChoosing>
---------- Recovery ------------
>p4d -f -r "C:\Program Files\Perforce\Server" -jr <yourBackupDirectory>\<prefixYouChose>.ckp.1
In my case, I had to use the -f flag due to errors when not using it.
Cheers,
Paul W

Copying just files not present with SCP

I need to move my web server directory to another server. I'd like to do it with a simple "scp -r destination:destdirectory". But in the meanwhile the directory will be filled with another stuff: so I'll take the old server down the time I need to move the newest file to the new one. How can I do an scp which is gonna write just the differences? So it'll take not much time, and I won't have to take the website down for too long!
Probably not at all, or just with pains. But if you have the possibility to use rsync, just do that. It automatically excludes files that haven't changed, and for changed files, it just transfers the differences.

linux script, standard directory locations

I am trying to write a bash script to do a task, I have done pretty well so far, and have it working to an extent, but I want to set it up so it's distributable to other people, and will be opening it up as open source, so I want to start doing things the "conventional" way. Unfortunately I'm not all that sure what the conventional way is.
Ideally I want a link to an in depth online resource that discusses this and surrounding topics in depth, but I'm having difficulty finding keywords that will locate this on google.
At the start of my script I set a bunch of global variables that store the names of the dirs that it will be accessing, this means that I can modify the dir's quickly, but this is programming shortcuts, not user shortcuts, I can't tell the users that they have to fiddle with this stuff. Also, I need for individual users' settings not to get wiped out on every upgrade.
Questions:
Name of settings folder: ~/.foo/ -- this is well and good, but how do I keep my working copy and my development copy separate? tweek the reference in the source of the dev version?
If my program needs to maintain and update library of data (gps tracklog data in this case) where should this directory be? the user will need to access some of this data, but it's mostly for internal use. I personally work in cygwin, and I like to keep this data on separate drive, so the path is wierd, I suspect many users could find this. for a default however I'm thinking ~/gpsdata/ -- would this be normal, or should I hard code a system that ask the user at first run where to put it, and stores this in the settings folder? whatever happens I'm going ot have to store the directory reference in a file in the settings folder.
The program needs a data "inbox" that is a folder that the user can dump files, then run the script to process these files. I was thinking ~/gpsdata/in/ ?? though there will always be an option to add a file or folder to the command line to use that as well (it processed files all locations listed, including the "inbox")
Where should the script its self go? it's already smart enough that it can create all of it's ancillary/settings files (once I figure out the "correct" directory) if run with "./foo --setup" I could shove it in /usr/bin/ or /bin or ~/.foo/bin (and add that to the path) what's normal?
I need to store login details for a web service that it will connect to (using curl -u if it matters) plan on including a setting whereby it asks for a username and password every execution, but it currently stores it plane text in a file in ~/.foo/ -- I know, this is not good. The webservice (osm.org) does support oauth, but I have no idea how to get curl to use it -- getting curl to speak to the service in the first place was a hack. Is there a simple way to do a really basic encryption on a file like this to deter idiots armed with notepad?
Sorry for the list of questions, I believe they are closely related enough for a single post. This is all stuff that stabbing at, but would like clarification/confirmation over.
Name of settings folder: ~/.foo/ -- this is well and good, but how do I keep my working copy and my development copy separate?
Have a default of ~/.foo, and an option (for example --config-directory) that you can use to override the default while developing.
If my program needs to maintain and update library of data (gps tracklog data in this case) where should this directory be?
If your script is running under a normal user account, this will have to be somewhere in the user's home directory; elsewhere, you'll have no write permissions. Perhaps ~/.foo/tracklog or something? Again, add a command line option, and also an option in the configuration file, to override this.
I'm not a fan of your ~/gpsdata default; I don't want my home directory cluttered with all sorts of directories that programs created without my consent. You see this happen on Windows a lot, and it's really annoying. (Saved games in My Documents? Get out of here!)
The program needs a data "inbox" that is a folder that the user can dump files, then run the script to process these files. I was thinking ~/gpsdata/in/ ?
As stated above, I'd prefer ~/.foo/inbox. Also with command-line option and configuration file option to change this.
But do you really need an inbox? If the user needs to run the script manually over some files, it might be better just to accept those file names on the command line. They could just be processed wherever, without having to move them to a "magic" location.
Where should the script its self go?
This is usually up to the packaging system of the particular OS you're running on. When installing from source, /usr/local/bin is a sensible default that won't interfere with package managers.
Is there a simple way to do a really basic encryption on a file like this to deter idiots armed with notepad?
Yes, there is. But it's better not to, because it creates a false sense of security. Without a master password or something, secure storage is not possible! Pidgin, for example, explicitly stores passwords in plain text, so that users won't make any false assumptions about their passwords being stored "securely". So it's best just to store them in plain text, complain if the file is world-readable, and add a clear note to the manual to warn the user what's going on.
Bottom line: don't try to reinvent the wheel. There have been thousands of scripts and programs that faced the same issues; most of them ended up adopting the same conventions, and for good reasons. Look at what they do, and mimic them instead of reinventing the wheel.
You can start with the Filesystem Hierarchy Standard. I'm not sure how well followed it is, but it does provide some guidance. In general, I try to use the following:
$HOME/.foo/ is used for user-specific settings - it is hidden
$PREFIX/etc/foo/ is for system-wide configuration
$PREFIX/foo/bin/ is for system-wide binaries
sym-links from $PREFIX/foo/bin are added to $PREFIX/bin/ for ease of use
$PREFIX/foo/var/ is where variable data would live - this is where your input spools and log files would live
$PREFIX should default to /opt/foo even though almost everyone seems to plop stuff in /usr/local by default (thanks GNU!). If someone wants to install the package in their home directory, then substitute $HOME for $PREFIX. At least that is my take on how this should all work.

In Perforce, can you rename a folder to the same name but cased differently?

Can I rename a folder in Perforce from //depot/FooBar/ to //depot/Foobar/?
I've tried this by renaming from //depot/FooBar/ to //depot/Temp/ to //Depot/Foobar/ but the end result ends up the same as //depot/FooBar/.
Once it is in Perforce, the case remains set. As mentioned by Johan you can obliterate, set the name up correctly, and add it in again. However, there is a slight gotcha....
If anyone else (running Windows) has already synced the wrong-cased version, then when they sync again the right one, it will not change the case on their PC. This is a peculiarity of the Windows file system acknowledging case but still being fundamentally case-independent.
If a number of users have synced, and it is not convenient to get them to remove-from-client too (and blasting the folders from their machines), then you can resort to a dark and dirty Perforce technique called "Checkpoint surgery". It's not for the fainthearted, but you do this:
Stop your server, take a checkpoint.
Using your favourite text editor that can handle multi-megabyte files, search & replace all occurances of the old case name with the new. You could of course use a script too.
Replay your checkpoint file to recreate the Perforce database meta data.
Restart your server.
This will affect all user client specs transparently, and so when they sync they will get the right case as if by magic.
It sounds hairy, but I've had to do it before and as long as you take care, backup, do a trial run etc, then all should be OK.
Maybe not needed anymore, but here's the official Perforce HowTo about changing file cases on Windows and Unix: http://answers.perforce.com/articles/KB/3448/?q=change+file+case
I'm not sure about directories, but we've had this problem with files. To fix it, we have to delete the file, submit that change, then p4 add the file with the correct case and submit the second change. Once that's done, unix users who have sync'ed the incorrect-case file have to p4 sync, then physically delete the file (because p4 won't update the case) and then p4 sync -f the file.
Our server is on Windows, so that might make a difference.
I guess it treats files and folders the same.
For files:
It depends (on whether you have a Windows or Unix server). We have this problem with our Windows perforce server (which versions our Java code), where very occasionally someone will check in a file with a case problem (this then causes compile errors because it's Java). The only way to fix this is to obliterate the file and resubmit it with the correct case.
I think you should remove the Perforce Cache, so that your modification can be shown.
You can rename with ABC rename to abc_TMP, then abc_TMP rename to abc, then clear cache.
Setps to clear cache:
Open windows user home folder (on windows7 ==> C:\Users\)
Locate the folder called ".p4qt"
Rename the folder to "old.p4qt"
Launch Perforce, now everything works!
NOTE: these steps will rest your default setting.
The question is over 3 years old, but I ran into an issue like this while doing a Subversion import into Perforce and figured the info I got could be useful to some. It's similar to the obliterate method, but helps you retain history. You use the duplicate command that may not have been available back then to retain the history. The process basically being:
Duplicate to temporary location.
Obliterate the location you just duplicated.
Duplicate from the temporary location to the renamed case location.
Obliterate the temporary location.
Through this you retain the history of file changes, but get them all in the new path as well. Unfortunately there will be no history of the path case change, but that seems to be unavoidable. Similar to other methods mentioned here, users will need to either manually rename the directories in their workspace or delete and re-sync to get the new path name.
Also, P4V caches the paths it shows in the tree so after doing this it may still show up as the old name. a p4 dirs command however will show the new case.

Resources