I am packaging and distributing a program I made for Windows,Linux and Mac. I plan to put the files and folders in zip archives.
If I set the correct folder and file permissions and then compress into zip and redistribute them, will those permissions be maintained when the user extracts them in Linux or Mac systems ? Or do they have to set the permissions themselves ?
zip does not store file permissions in the archive.
tar archives will preserve file permissions on Linux and OS X. I have no idea what happens on Windows. If you can test things out on Windows and it works, this is probably your best bet. It probably depends on what tool people use to unpack the archives.
Another option would be to create an installer, although there are few non-commercial options for creating cross-platform installers. Wikipedia has a list.
An installer is your best option here.
Lets me explain a bit better why.
Windows has these permissions:
Modify
Read & Execute
Read
Write
Which are assigned to Groups or Usernames,
Unix based systems have:
Read
Write
Execute
Which can be assigned to owner, group and others.
Has you can see, its difficult to map permissions from one system to another, since the filesystems handle permissions differently.
However some zip utilities like Info-Zip supports Unix based filesystem features, such as user and group IDs, file permissions, and support for symbolic links. It also support NTFS filesystem permissions, and will make an attempt to translate from NTFS permissions to Unix permissions or vice-versa when extracting files. This can result in potentially unintended combinations, e.g. .exe files being created on NTFS volumes with executable permission denied.*
If you are planning on distributing your program, an installer is indeed your best solution.
*From wikipedia: Zip (file format)
Related
I'm a beginner in linux.I have a question on filesystem that is it possible to make all files under a directory read-only without changing permissions?
No it is not possible. The write permission grants the ability to write a file. So that you need to change it anyway to make the file read-only for specific user or group of users.
You'd probably like to read this at spare time.
If you have suitable privileges, and if the filesystem is not critical to the machine (do not try this with "/", your root filesystem), you can remount the filesystem read-only. The details differ slightly from one system to another, but a useful discussion is found here:
https://askubuntu.com/questions/296331/how-to-mount-a-hard-disk-as-read-only-from-the-terminal
that applies to Linux and BSDs.
Because this does not actually modify the files, you can undo this by remounting the filesystem again, with read/write permissions, e.g., "rw" where the "ro" option was used. For specific information you should read the manpage(s) for mount and fstab for the system you are using.
Are the settings or configuration specifics of a printer on a *nix system using CUPS stored in a file? My assumption is yes, as *nix systems seem to use files for everything as opposed to using a registry system as does Windows. If so, where are such files located? Are they capable of having their file permissions modified, and if so, what could cause such a thing to occur in a non-manual way?
This question relates to one of my other questions in helping to explore a single, individual theory toward an answer there, but is decidedly separate.
Check on /etc/cups, for printers the file is printers.conf.
They can have permissions modified since they usually belong to the lp group, not a single user. Check cron jobs, system updates and any other cups interface that your distribution provides.
I have a doubt. In Linux everything is file, and using inode Linux maintains association between files and folder. But in Windows folder is not a file (may be I am wrong), so how it is possible to map file and folder. Where association information is kept in Windows OS.
Thnaks in advance.
You're confusing levels of abstraction. Sure, in Linux, /dev/null looks like a file, since it can be accessed with file API's.That doesn't mean it has an inode.
In reverse, on Windows (NTFS) folders are quite similar to files, except that the file API's refuse to operate on folders. The OS internally understands the similarity, though.
I'm currently designing a Linux-based system. Users of the system will be allowed to download contents, i.e. programs, from the Internet. The contents will be distributed in zip packages given special extension names, e.g. .cpk instead of .zip, and with zero compression.
I want to give users the same experience found in iOS and Android, in which contents are distributed in contained packages and run from there.
My question is that can I make my Linux system to run programs from inside the packages without unzipping them? If not, then is there another approach to what I'm after in Linux?
Please note that I don't want to extract contents into a temp folder and delete them after execution because that might take longtime, specially for large contents. That will also double the storage space requirements for running the contents.
Thank you in advance.
klik (at least in the klik2 CMG format) used an zISO image, which can be mounted by the kernel or by a FUSE client, rather than a zip. You could use other filesystem types that are supported by the kernel or via FUSE. Maybe fuse-zip is worth a shot?
You could also modify the loader to read directly out of the bundle. For example, Android's Dalvik VM can load dex files directly from apk bundles, which are effectively zip files. (Native code on Android, however, still needs to be unpacked first, and does take more time and space. Modifying the native loader is… tricky.)
Coming from Windows background here.
Is it an acceptable practice for GUI Linux applications to store their data files (not user-specific) at hard-coded locations (e. g. /etc/myapp/stuff)? I couldn't find any syscalls that would return the preferred directory for app data. Is there a convention out there as to what goes where?
/opt/appname/stuff according to the Linux Filesystem Hierarchy Standard
Your distribution's packaging system likely provides ways to handle common installation paths. What distribution are you using?
Generally speaking, yes there is a convention. On most Linux systems, application configuration files are typically located at /etc/appname/. You'll want to consult the LSB (Linux Standard Base) and the Linux FHS (Filesystem Hierarchy Standard) for their respective recommendations.
Also, if you are targeting your application towards a specific Linux distro, then that distro vendor probably has their own specific recommendations as far as packaging and related-conventions are concerned. You'll want to look at your distro vendor's developer pages for more information.
Configuration files for processes with elevated privileges are generally stored in /etc. Data files for processes with elevated privileges (Web Server, Mail Server, Chat Server, etc.) are generally stored in /var. And that's where consistency ends. Some folks say you start with the location to store them (/etc|/var) then have an appname sub-folder for your app, then continue from there as necessary.
If you're not a system daemon with elevated privileges, your only consistent choice is a dot directory in the launching user's home directory. I think the Free Desktop Standards (XDG) specify ~/.config for per-user configuration, and ~/.cache for replaceable static and/or generated data you need to save.
Looking at my Home Directory, a few key dot directories I have are:
~/.cache
~/.config
~/.irssi
~/.maildir
~/.mozilla
~/.kde
~/.ssh
~/.vnc
[edit]
While not a syscall, the XDG specifications I reference are at http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
There are certain conventions.
System-wide, readable/editable (text-based) configuration files go in /etc/appname/.
System-wide, per-machine binary data files that change (eg. binary databases) go in /var/*/appname/ - /var/cache/appname/, /var/spool/appname/ and /var/lib/appname/ are the most common.
System-wide binary data files that could notionally be shared between machines (eg. things like graphics and sound files) go in /usr/share/appname/.
The full paths that Unix/Linux/GNU applications use to store config files and other data is usually set when an application is configured prior to compilation. These paths then get hard-coded into the compiled binary (you can see examples of this by running strings(1) over some existing executables).
That is, these types of paths are build-time configurable, not run-time configurable by default. Many apps will support command line options to specify where a configuration file is, and that configuration file will usually contain paths for other application resources. This allows an application to run with minimal configuration (built-in paths) but also allows a site to customise the paths completely.
Under Linux, only the basic services (opening a file, doing networking and interprocess communication etc) are provided as system calls. The rest is done using libraries.
If you are coding a GUI application, you should look into your toolkit's documentation to see if it provides a mechanism for managing defaults. Both KDE and Gnome have one for instance.