THE SCENARIO
I'm developing a Root FS for some embedded Linux device. It is sitting on the host, exported via NFS and my development board mounts is under "/".
The workflows that I need are:
- to share my FS to other developers(they have with their own dev. boards)
- to backup my Root FS onto some "server"
- to deploy my Root FS onto flash-disks or other media
- track changes in specific files in my Root FS, branching&merging,roll back etc.
Guys, this seems to me as a Version Control scenario, and I even use git.
THE PROBLEM
As you know Git(and svn/mercurial/bazaar too !) 1) does not store special files (device files under /dev etc.) 2) does not store file owners and permissions.
I want to store everything and AS IS.
THE QUESTION:
Do you know some VCS that will do the job ?
Or may be you know about another (but simple) solution for doing my scenarios ?
IS IT A COMMON PROBLEM...
I believe that it is, because till now I've heard about scripts/hooks/custom soft that everybody(!) works out for his purposes. All I need is an all-eating-VSS
Thank you !!
Having done something similar (developing firmware for an embedded Linux OS), I've found that it's better to put device file creation into a script called by your build system, rather than to store device files directly on the development machine. Then the script that creates the files goes into version control, instead of the files themselves, and (BONUS) you don't need to be root to modify them. Run the build through fakeroot instead.
I suppose this doesn't directly answer your question, but it may be worth thinking about revising your development model. It's NEVER a good idea to run your build as root, because what happens if you accidentally have a "/" in front of a common path? You may inadvertently replace /bin with a whole bunch of links to busybox built for a different architecture.
This is the tool for you:
http://fsvs.tigris.org/
it has svn backend.
I know this seems a little obvious, but as you haven't mentioned it: Have you considered mechanisms to put all your special files into a regular file, like, for example, into a tar archive? You could store that just fine with any version control system, and as filesystems have lots of binary data anyway diffs between two revisions of a full root filesystem aren't that useful anyway, so you might even not lose too many of the features your version control system provides.
initramfs is a good answer to the userid groupid, permissioon problem. In your kernel source directory, there is scripts/gen_initramfs_list.sh.
This script allows you to build an initramfs archive from several sources. You can for example, specify :
a directory : The files and directory found in this base directory will be at the root of your file system.
a file liste : it is a text file, very useful to create directory, files and special device files. See example below
If you develop as non root, and your rootfs is in rootfsdir, then probably the file in rootfsdir are owned by you. gen_initramfs_list can translate your uid, gid into 0, 0. Here is an exemple command line :
gen_initramfs_list -u $MYUID -o initramfs.gz rootfsdir/ device.txt
Where device.txt contains :
# This is a very simple, default initramfs
dir /dev 0755 0 0
nod /dev/console 0600 0 0 c 5 1
dir /root 0700 0 0
# file /kinit usr/kinit/kinit 0755 0 0
# slink /init kinit 0755 0 0
Then you can use standard version control for your rootfsdir content, and add the device.txt file under version control, and here you are : content and file attribute are versionned :).
I don't know if you can change the permission and uid/gid of a file in a directory source via a filelist source, but this would be a logical feature.
Of course you can start with minimal root fs, from which you mount your existing nfs_export.
It is a common problem, and gen_initramfs_list is the tool to solve it.
Why not just use rsync? Something like rsnapshot (http://www.rsnapshot.org) will do what you want. Alternatively Unison (http://www.cis.upenn.edu/~bcpierce/unison/) is explicitly designed for this - it describes itself as a cross-platform file synchronisation technology with version control, and might be what you need.
Related
I have a video files in:
/home/private/movies/video1.mkv
/home/private/movies/video2.mkv
/home/private/movies/video3.mkv
I have hardlinks to those mkv files in:
/home/minidlna/videos/video1.mkv
/home/minidlna/videos/video2.mkv
/home/minidlna/videos/video3.mkv
My minidlna share is:
/home/minidlna
The video files show up on the minidlna cilent (my TV) after I do a full rescan of the minidlna share, however, they don't show up if I create new hardlinks with the inotify interval set really low.
The files do show up if they are not hardlinks.
My guess is that there seems to be a problem with minidlna and the way it processes the 'filesystem changes' using 'inotify'. Perhaps a hardlink isn't necessary a 'change' to notify minidlna.
My video library is rather large and continually doing rescans seems very inefficient and takes a long time. I would appreciate if someone can shed some light on this or have a workaround.
I'm running minidlna version 1.1.4
It appears it is indeed a problem with minidlna.
Depending on your use case, maybe you can create the new video file in the minidlna directory and make the one in your private movies a hardlink. The resulting filesystem will be the same, but now the first operation minidlna sees should be a full-fledged create, and therefore work.
Looks like there's no workaround to my exact problem and unfortunately my setup doesn't allow reversing the minidlna share <> hardlink directory.
The only solution I found was to rebuild minidlna RPM with IN_CREATE in inotify.c (more details here - http://sourceforge.net/p/minidlna/bugs/227/)
Hopefully Readynas makes that the default for future builds.
I'm using autotools to package my software and compile. The problem I'm having is that during the installation process, I'm creating a folder in /etc/myapp and in that folder I'm placing several files that I need. In addition, when my software is running, I'm generating files and storing them in that same location (/etc/myapp). When I execute "sudo make uninstall", all of the files that were initially installed by using "sudo make install" are removed from /etc/myapp. However, the files that are generated by the software and store in that same spot are not removed and now I have left over files.
Where in the Makefile.am files would I specify to remove the entire /etc/myapp folder during the uninstall process?
FYI, I'm using Ubuntu 12.
Thank you
D
In your Makefile.am, you can create a target named uninstall-hook which will delete your generated files:
uninstall-hook:
rm -f $(DESTDIR)$(datadir)/my_generated_file $(DESTDIR)$(datadir)/my_other_generated_file
Or even:
uninstall-hook:
rm -rf $(DESTDIR)$(datadir)
Your question involves more than just tooling; it involves policy. What type of files are you creating? If they can be lost over a reboot, they (probably) belong under /var/run/myapp. If they are data files, they probably belong in $(prefix)/share/myapp. I say "probably" because it depends on the platform, and the user. Most debian users will want such files in the locations I mention above, but they may have reasons for putting them elsewhere. The important point is that it is the user's choice, not yours. As the package maintainer, you don't get to choose /etc/myapp. You need to configure your package to make those choices available to the user. The typical way to do that is to use automake's _DATA primaries and the 'sysconfdir', 'sharedstatedir', 'localstatedir', and 'pkgdatadir' family of variables.
I know that, whatever data is placed in package/component dir/data, will be copied to the install directory. What I mean is if I have a binary, readme, license.txt inside package/component dir/data/myapp, package/component dir/data/readme, package/component dir/data/license.txt and if I choose my target installation dir to be “/opt/myfirstapp”, then inisde /opt/myfirstapp, I will have 3 files copied, myapp, readme, license.txt.
Having said that, I also have a “/usr” directory with in package/component dir/data/, however this is not the standard “/usr” which will be inside root “/”, it is just a replica. Now inside my replica “/usr” I have some directory hierarchy and some files, like /usr/bin/myapp, /usr/lib/libmyapp.so, /usr/share/icons” and many more, infact a lot. Now I want the replica “/usr” content to be copied to “/usr” (the original usr inside root folder). I should also make sure that I just add new contents to “/usr” (root /usr), but delete any existing content.
Question is clear, some files inside my data directory will have to go to target install dir, but some selected ones (for ex: /usr) will have to be copied to other paths. How do I achieve this.
Currently we have the same problem in my company: we need 2 target directories, one for the exe and one for the libraries (well, it's a bit more complex but in few words...).
After having spoken with Qt support and got the answer that it's actually not possible ("It is possible only after extracting. After extraction, you can use copy or move operation, unfortunately there is currently no other way.") I decided to use the AdminTargetDir as the second target directory. This because there's no other way to pass dynamic variables to the IFW. So after installation I call a "finalizeInstall_patch.bat" file passing the TargetDir and AdminTargetDir and this will move the libraries directory from TargetDir to AdminTargetDir. Why a .bat patch file ? because it's actually not possible to move a directory using the methods provided by the IFW. Qt support just opened a suggestion-ticket for our problem: https://bugreports.qt-project.org/browse/QTIFW-595
I hope that this answer will help others having same similar problems.
NOTE: There is a way to move a directory (on Windows), calling addOperation("Execute", "cmd /C move source dest...") but this brings to other problems out of topic here.
This worked for us (Qt Installer, macOS):
var args = ["cp", "-R", "#TargetDir#/MyApp.app", "/Applications"];
component.addOperation("Execute", args);
I am writing a small command line utility. It should hopefully be able to run on OSX, UNIX and Linux.
It needs to save a few preferences somewhere, like in a small YAML config file.
Where would one save such a file?
Language: Python 2.7
OS: *nix
Commonly, these files go somewhere like ~/.rc (eg: ~/.hgrc). This could be the path to a file, or to a directory if you need lots of configuration settings.
For a nice description see http://www.linuxtopia.org/online_books/programming_books/art_of_unix_programming/ch10s03.html
I would avoid putting the file in the ~ directory only because it has gotten totally flooded with crap. The recent trend, at least on ubuntu, is to use ~/.config/<appname>/ for whatever dot files you need. I really like that convention.
If your application is named "someapp" you save the configuration in a file such as $HOME/.someapp. You can give the config file an extension if you like. If you think your app may have more than one config file you can use the directory $HOME/.someapp and create regular-named (not hidden) files in there.
Many cross-platform tools use the same path on OS X as on linux (and other POSIX/non-Windows platforms). The main advantage of using the POSIX locations isn't saving a few lines of code, but saving the need for Mac-specific instructions, and allowing Mac users to get help from the linux users in the community (without any need to translate their suggestions).
The other alternative is to put them in the "Mac-friendly" locations under ~/Library instead. The main advantage of using the Mac locations is basically "Apple says so"—unless you plan to sandbox your code, in which case the main advantage is that you can do so.
If you choose to use the Library locations, you should read About the OS X File System and OS X Library Directory Details in the File System Programming Guide, but here's the short version:
Almost everything: Create a subdirectory with your app's name or bundle ID (unless you're going out of your way to set a bundle ID, you'll get org.python.python, which you don't want…) under ~/Library/Application Support. Ideally you should use APIs like -[NSFileManager URLForDirectory:inDomain:appropriateForURL:create:error:] to get the path; if not, you have to deal with things like localization, sandbox containers, etc. manually.
Anything that can be easily re-created (so it doesn't need to be backed up, migrated, etc.): An identically-named subdirectory of ~/Library/Caches.
Preferences: Use the NSUserDefaults or CFPreferences APIs instead. If you use your own format, the "old" way of doing things is to create a subdirectory under ~/Library/Preferences named with your app's name or bundle ID, and put your files in that. Apple no longer recommends that, but doesn't really recommend an alternative (short of "use CFPreferences, damnit!"); many apps (e.g., Aquamacs) still do it the old way, but others instead pretend they're not preferences and store them under Application Support.
In Python, this works as follows (leaving out the error handling, and assuming you're going by name instead of setting a bundle ID for yourself):
from Foundation import *
fm = NSFileManager.defaultManager()
appsupport = (fm.URLForDirectory_inDomain_appropriateForURL_create_error_(
NSApplicationSupportDirectory, NSUserDomainMask, None, True, None)[0].
URLByAppendingPathComponent_isDirectory_(
appname, True))
caches = (fm.URLForDirectory_inDomain_appropriateForURL_create_error_(
NSCachesDirectory, NSUserDomainMask, None, True, None)[0].
URLByAppendingPathComponent_isDirectory_(
appname, True))
prefs = NSUserDefaults.persistentDomainForName_(appname)
hi all:
recently i'm working on make checkpoint on linux process and encountered a problem,it looks like that when i munmap memory map of the executable to current process,the symlink /proc/self/exe is dead.what i want is to make this symlink pointing to a other executable(the one for my resumed processs),is that possible?i tried delete it and recreate, permission denied. english is not my native language, i hope i've made my point,thanx
prctl(PR_SET_MM_EXE_FILE, ...)
Supersede the /proc/pid/exe symbolic link with a new one pointing to a new executable file identified by the file descriptor provided in arg3 argument. The file descriptor should be obtained with a regular open(2) call.
No. /proc is completely managed by the kernel and does not allow changes like that.
But you may be able to start a new process (with fork() perhaps) and map your memory snapshot into that.