[opensuse-programming] Where to save "global" data files from application

newer
[opensuse-programming] how to stop...

opensuse＠sky-bizz.com

27 Jul 2007 27 Jul '07

17:29

Hello [at first: i am not new to developing software, but i am slightly new to developing linux-software :)] i'm just developing an command line tool for linux (c++), which has to save its data into a single file in the filesystem, undependently from running user. its handling is best described like or compared with "updatedb". there is only one data-file for all users. in which folder should i create the application's data-file, and whats about the needed rights on it? can this application "ask" for getting needed privileges like on windows? is there a special folder intended for handling such things? if yes, what folder? kind regards for any help hagen --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org

Show replies by date

Jerry Feldman

27 Jul 27 Jul

20:09

On Fri, 27 Jul 2007 19:29:26 +0200 opensuse@sky-bizz.com wrote:

...

Hello

[at first: i am not new to developing software, but i am slightly new to developing linux-software :)]

i'm just developing an command line tool for linux (c++), which has to save its data into a single file in the filesystem, undependently from running user. its handling is best described like or compared with "updatedb". there is only one data-file for all users.

in which folder should i create the application's data-file, and whats about the needed rights on it? can this application "ask" for getting needed privileges like on windows?

is there a special folder intended for handling such things? if yes, what folder?

In Unix and Linux systems every directory (eg folder) and every file has a set of permissions and ownerships: Ownerships are the owner, the group, everyone else Permissions are: read, write, execute. The execute bit for directories means that you can enter that directory. For regular files, it means you can execute the file. This is different than for Windows where executable files must have specific extensions. Normally in Linux, user-oriented data is saved on a per-user basis, in the user's home directory. If you want to have a global database of information, just come up with where you want to put it. Let's saye your application is called FuBAR. You might want to install it in /usr/local/FuBAR where FuBAR might have subdirectories, bin - for executables, lib for libraries, data for shared data, conf for config files. There are a number of ways you can have multiple users write to the same file. One way is to use the setuid or setgid bits, but that is dangerous. Probably a safer way is to set up the shared data file rw by the FuBAR group, and anyone who can use it must be in that group. There is a command, newgrp(1) that allows a user to change to any group he is a member of. The cvs command works similar to this so you can check files into and out of a shared repository. -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

Randall R Schulz

21:17

On Friday 27 July 2007 13:09, Jerry Feldman wrote:

...

...

In Unix and Linux systems every directory (eg folder) and every file has a set of permissions and ownerships: Ownerships are the owner, the group, everyone else Permissions are: read, write, execute. The execute bit for directories means that you can enter that directory.

Where "enter" means the kernel will perform a lookup action in that directory. This can be as part of opening a file, changing directory, performing an exectue operation or even something less common, like the chroot system call. It is enforced / required whether the directory in question is the ultimate target of the operation or just encountered as an intermediate directory in a path-name lookup that goes deeper into the directory hierarchy.

...

...

Randall Schulz --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org

Keith Roberts

20:11

New subject: [opensuse-programming] Where to save "global" data files from application

A standard place to place it would be in /etc, as a text file called yourappname.data, or even under it's own subdirectory, where you could also add a runtime configuration file for your application, called for example, /etc/yourappname/yourapp.conf . Regards Keith On Fri, 27 Jul 2007, opensuse@sky-bizz.com wrote:

...

To: opensuse-programming@opensuse.org From: opensuse@sky-bizz.com Subject: [opensuse-programming] Where to save "global" data files from application

Hello

[at first: i am not new to developing software, but i am slightly new to developing linux-software :)]

i'm just developing an command line tool for linux (c++), which has to save its data into a single file in the filesystem, undependently from running user. its handling is best described like or compared with "updatedb". there is only one data-file for all users.

in which folder should i create the application's data-file, and whats about the needed rights on it? can this application "ask" for getting needed privileges like on windows?

is there a special folder intended for handling such things? if yes, what folder?

kind regards for any help hagen

--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org

-- ------------------------------------------------------------ http://www.karsites.net http://www.raised-from-the-dead.org.uk This email address is challenge-response protected with http://www.tmda.net ------------------------------------------------------------ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org

Curt, WE7U

20:20

On Fri, 27 Jul 2007, Keith Roberts wrote:

...

A standard place to place it would be in /etc, as a text file called yourappname.data, or even under it's own subdirectory, where you could also add a runtime configuration file for your application, called for example, /etc/yourappname/yourapp.conf .

Perhaps stick to the conventions listed in the FHS? http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard -- Curt, WE7U: XASTIR: "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U The world DOES revolve around me: I picked the coordinate system! --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org

Greg Freemyer

20:57

On 7/27/07, Curt, WE7U wrote:

...

On Fri, 27 Jul 2007, Keith Roberts wrote:

...
A standard place to place it would be in /etc, as a text file called yourappname.data, or even under it's own subdirectory, where you could also add a runtime configuration file for your application, called for example, /etc/yourappname/yourapp.conf .

Perhaps stick to the conventions listed in the FHS?

http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

Even with that spec. there is not really a general answer. At least not one I see. Based on experience only, people mostly do one of two things: A) create there own directory / partition / mount point in the root if there is going to be a lot of data. This is particularly true if it is gone to be a main function of the computer. ie. /data, /GIS-info, /source-code-for-our-teams-mega-application etc. B) if there is not going to be enough data to justify that, I believe most Linux apps are using /var/lib/<appname> Sort of a strange place. I always expect /var/lib to have libraries or shared libraries in it like /lib and /usr/lib, but take a look. I don't think you will find any. Instead you find a bunch of application global data. === As to /etc/<appname>, that should only have a small amount of configuration data. One of the config variables may in turn point to the real repository, but please don't put several GB or more of data in /etc/<appname> Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org

Curt, WE7U

21:13

On Fri, 27 Jul 2007, Greg Freemyer wrote:

...

A) create there own directory / partition / mount point in the root if there is going to be a lot of data. This is particularly true if it is gone to be a main function of the computer.

"A" above is not considered good practice, at least not from what I've seen.

...

/data, /GIS-info, /source-code-for-our-teams-mega-application etc.

However, one can create application-specific directories in /opt, and in fact the LSB spec requires it. I work on an open-source app that normally installs to /usr/local/* directories, including it's system-wide configs in /usr/local/share/<app-name>/*. In it's LSB form it installs to /opt/<app-name>/* instead.

...

B) if there is not going to be enough data to justify that, I believe most Linux apps are using /var/lib/<appname>

Depends. If they're distributed with the OS they sometimes do that. If they're not part of the OS, they usually install into /usr/local/* instead so that they're separate from any OS files. If you're creating your own application, separate from any OS distribution, consider putting it in /usr/local or /opt. As an example, the app I spoke of installs into one or the other of these heirarchies. The first is the default, the 2nd is if you compile it as a Linux Standard Base package (LSB): /usr/local/bin/ (executables) /usr/local/lib/<app-name>/ (scripts) /usr/local/share/<app-name>/ (configs, maps, sound files, etc) /usr/local/share/doc/<app-name>/ (README's, INSTALL's, FAQ, LICENSE) /usr/local/man/man1/ (man pages) -or- /opt/<app-name>/bin/ (executables) /opt/<app-name>/lib/<app-name>/ (scripts) /opt/<app-name>/share/<app-name>/ (configs, maps, sound files, etc) /opt/<app-name>/doc/<app-name>/ (README's, INSTALL's, FAQ, LICENSE) /opt/<app-name>/man/man1/ (man pages) -- Curt, WE7U: XASTIR: "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U The world DOES revolve around me: I picked the coordinate system! --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org

Greg Freemyer

21:39

On 7/27/07, Curt, WE7U wrote:

...

On Fri, 27 Jul 2007, Greg Freemyer wrote:

...
A) create there own directory / partition / mount point in the root if there is going to be a lot of data. This is particularly true if it is gone to be a main function of the computer.

"A" above is not considered good practice, at least not from what I've seen.

...
/data, /GIS-info, /source-code-for-our-teams-mega-application etc.

However, one can create application-specific directories in /opt, and in fact the LSB spec requires it. I work on an open-source app that normally installs to /usr/local/* directories, including it's system-wide configs in /usr/local/share/<app-name>/*. In it's LSB form it installs to /opt/<app-name>/* instead.

So your saying that if an application is data intensive; lets say a GIS system (Geographic Information System), you would put a TB of data under /opt/GIS/data. Maybe your right, but in "my experience" large datasets get put in the root. Basically large datasets are almost always put on a dedicated partition / LV in my experience. And in turn those partitions are mounted at the root level. FYI: Much of my experience with this class of app is UNIX, not Linux, so maybe the Linux philosophy is different, but I really have a hard time imagining large datasets mounted anywhere but the root.

...

...
B) if there is not going to be enough data to justify that, I believe most Linux apps are using /var/lib/<appname>

Depends. If they're distributed with the OS they sometimes do that.

If they're not part of the OS, they usually install into /usr/local/* instead so that they're separate from any OS files.

If you're creating your own application, separate from any OS distribution, consider putting it in /usr/local or /opt. As an example, the app I spoke of installs into one or the other of these heirarchies. The first is the default, the 2nd is if you compile it as a Linux Standard Base package (LSB):

/usr/local/bin/ (executables) /usr/local/lib/<app-name>/ (scripts) /usr/local/share/<app-name>/ (configs, maps, sound files, etc) /usr/local/share/doc/<app-name>/ (README's, INSTALL's, FAQ, LICENSE) /usr/local/man/man1/ (man pages)

My impression is that /usr as a whole is meant to hold fairly stable data. So if the applications data is fairly stable than /usr/local certainly makes a lot of sense.

...

-or-

/opt/<app-name>/bin/ (executables) /opt/<app-name>/lib/<app-name>/ (scripts) /opt/<app-name>/share/<app-name>/ (configs, maps, sound files, etc) /opt/<app-name>/doc/<app-name>/ (README's, INSTALL's, FAQ, LICENSE) /opt/<app-name>/man/man1/ (man pages)

I notice the Opensuse 10.2 also has /var/opt/gnome. Never noticed that before. As a guess, at least a few developers convinced Suse that /var/opt was the best place for a /opt application to store its dynamic data. Maybe that is the best choice of all. Certainly makes more sense to me than /var/lib which has never made sense to me. Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org

Randall R Schulz

22:15

On Friday 27 July 2007 14:39, Greg Freemyer wrote:

...

On 7/27/07, Curt, WE7U wrote:

...
On Fri, 27 Jul 2007, Greg Freemyer wrote:

...
A) create there own directory / partition / mount point in the root if there is going to be a lot of data. This is particularly true if it is gone to be a main function of the computer.

"A" above is not considered good practice, at least not from what I've seen.

...
/data, /GIS-info, /source-code-for-our-teams-mega-application etc.

However, one can create application-specific directories in /opt, and in fact the LSB spec requires it. I work on an open-source app that normally installs to /usr/local/* directories, including it's system-wide configs in /usr/local/share/<app-name>/*. In it's LSB form it installs to /opt/<app-name>/* instead.

So your saying that if an application is data intensive; lets say a GIS system (Geographic Information System), you would put a TB of data under /opt/GIS/data.

Maybe your right, but in "my experience" large datasets get put in the root.

Gasp! Never! If the data is locally derived it might go in /var or /usr/local or if extremely large may require special treatment in the application so it could be distributed over multiple directories and mass storage units (as, e.g., RDBMSes often do). If the data is a large read-only dataset (say, the topographic base maps in a GIS application), it may even remain on external media (DVDs or, someday soon, BlueRay or HD-DVD discs), though that usually has unacceptably slow transfer rates and high latencies. But in the root?? No way!

...

Basically large datasets are almost always put on a dedicated partition / LV in my experience. And in turn those partitions are mounted at the root level.

I cannot say I think that's either common or a good idea. I've worked in very large-scale data processing shops that use Linux throughout (Amazon.com) and we never put anything application-specific in the root directory. In fact, management of hosts was stratified so that the infrastructure people owned the kernel and all the baseline OS files and directories. There is also monitoring and provisioning infrastructure common to all hosts. Then there was a whole elaborate system for deploying application packages based on host classes and those application-specific packages had their own base directory. Admittedly, Amazon.com is an outlier. They have huge scaling requirements and a staggering range of disparate applications (many not even customer-facing). It still boggles my mind that it works at all...

...

FYI: Much of my experience with this class of app is UNIX, not Linux, so maybe the Linux philosophy is different, but I really have a hard time imagining large datasets mounted anywhere but the root.

You need to expand your imagination. The root directory on a production system should probably never be touched at all. It's best left to the base operating system itself.

...

...

Greg

Greg Freemyer

28 Jul 28 Jul

00:41

On 7/27/07, Randall R Schulz wrote:

...

On Friday 27 July 2007 14:39, Greg Freemyer wrote:

...
On 7/27/07, Curt, WE7U wrote:

...
On Fri, 27 Jul 2007, Greg Freemyer wrote:

...
A) create there own directory / partition / mount point in the root if there is going to be a lot of data. This is particularly true if it is gone to be a main function of the computer.

"A" above is not considered good practice, at least not from what I've seen.

...
/data, /GIS-info, /source-code-for-our-teams-mega-application etc.

However, one can create application-specific directories in /opt, and in fact the LSB spec requires it. I work on an open-source app that normally installs to /usr/local/* directories, including it's system-wide configs in /usr/local/share/<app-name>/*. In it's LSB form it installs to /opt/<app-name>/* instead.

So your saying that if an application is data intensive; lets say a GIS system (Geographic Information System), you would put a TB of data under /opt/GIS/data.

Maybe your right, but in "my experience" large datasets get put in the root.

Gasp! Never!

If the data is locally derived it might go in /var or /usr/local or if extremely large may require special treatment in the application so it could be distributed over multiple directories and mass storage units (as, e.g., RDBMSes often do). If the data is a large read-only dataset (say, the topographic base maps in a GIS application), it may even remain on external media (DVDs or, someday soon, BlueRay or HD-DVD discs), though that usually has unacceptably slow transfer rates and high latencies.

But in the root?? No way!

...
Basically large datasets are almost always put on a dedicated partition / LV in my experience. And in turn those partitions are mounted at the root level.

I cannot say I think that's either common or a good idea. I've worked in very large-scale data processing shops that use Linux throughout (Amazon.com) and we never put anything application-specific in the root directory. In fact, management of hosts was stratified so that the infrastructure people owned the kernel and all the baseline OS files and directories. There is also monitoring and provisioning infrastructure common to all hosts. Then there was a whole elaborate system for deploying application packages based on host classes and those application-specific packages had their own base directory.

Admittedly, Amazon.com is an outlier. They have huge scaling requirements and a staggering range of disparate applications (many not even customer-facing). It still boggles my mind that it works at all...

...
FYI: Much of my experience with this class of app is UNIX, not Linux, so maybe the Linux philosophy is different, but I really have a hard time imagining large datasets mounted anywhere but the root.

You need to expand your imagination. The root directory on a production system should probably never be touched at all. It's best left to the base operating system itself.

I'm talking about creating a mount point in the root directory and then mounting your big data partition there. I really don't see why admins would dislike /data or whatever as the mount point. Last time I worked with a Oracle database, I'm sure thats what they were doing. (I did not do the install, so maybe the person who did overrode the defaults.) Seriously, if you have a TB of data your mounting as a single partition from a SAN as a local drive, where are you saying to mount it. The idea of a mount point in /usr/local/data for instance just seems crazy to me, especially if /usr is itself a separate filesystem. Another example is your building your box exclusively to be a samba fileserver. Once again, I think the typical thing to do would be create a big raid 5 (or 10) based volume, mount it at the root level and then share if via samba. Strange. Your disturbed I would mount big dedicated data partitions at the root level, and I'm disturbed its not standard practice. :( Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org

Randall R Schulz

01:14

On Friday 27 July 2007 17:41, Greg Freemyer wrote:

...

...

...
You need to expand your imagination. The root directory on a production system should probably never be touched at all. It's best left to the base operating system itself.

I'm talking about creating a mount point in the root directory and then mounting your big data partition there. I really don't see why admins would dislike /data or whatever as the mount point.

I understand that, but it's still a bad idea. The root directory and partition belong exclusively to the operating system. It's ill-advised to usurp that ownership.

...

Last time I worked with a Oracle database, I'm sure thats what they were doing. (I did not do the install, so maybe the person who did overrode the defaults.)

I don't doubt that Oracle (or MySQL or PostgreSQL, etc.) are flexible enough to do this, but that does not mean it's a good idea.

...

Seriously, if you have a TB of data your mounting as a single partition from a SAN as a local drive, where are you saying to mount it.

Did you mean to use a question mark? Assuming so, I mean you should mount it in some place dedicated to data expansion, not the root file system, which belongs to the operating system, obviously! God, man... Do you think this is for use on a personal computer? We're obviously talking about application or data servers here.

...

The idea of a mount point in /usr/local/data for instance just seems crazy to me, especially if /usr is itself a separate filesystem.

Your insanity is your own, thankfully.

...

Another example is your building your box exclusively to be a samba fileserver. Once again, I think the typical thing to do would be create a big raid 5 (or 10) based volume, mount it at the root level and then share if via samba.

Being a file server and being and application host are not really the same thing, are they? No, they're not. Regardless, the root directory is not a playground for application or file service deployment. In fact, the latter makes an even weaker case, since shares are seen by clients independent of their location in the serving host's file system and there is no justification at all for using the root to mount local file system volumes.

...

Strange. Your disturbed I would mount big dedicated data partitions at the root level, and I'm disturbed its not standard practice. :(

Presumably you meant "You're." Please proofread your posts. As to your apparent sadness over not having to organize your deployments, that's something you'll have to deal with on your own.

...

Greg

RRS --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org

Greg Freemyer

01:48

On 7/27/07, Randall R Schulz wrote:

...

On Friday 27 July 2007 17:41, Greg Freemyer wrote:

...
...

...
You need to expand your imagination. The root directory on a production system should probably never be touched at all. It's best left to the base operating system itself.

Last time I worked with a Oracle database, I'm sure thats what they were doing. (I did not do the install, so maybe the person who did overrode the defaults.)

I don't doubt that Oracle (or MySQL or PostgreSQL, etc.) are flexible enough to do this, but that does not mean it's a good idea.

Per a very recent release of Oracle: Oracle(r) Database Installation Guide 10g Release 2 (10.2) for Linux x86 http://download.oracle.com/docs/cd/B19306_01/install.102/b15660/app_ofa.htm#... Oracle is still recommending the following mount points be used: /u01 /u02 /u03 /u04 Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org

Randall R Schulz

02:17

On Friday 27 July 2007 18:48, Greg Freemyer wrote:

...

On 7/27/07, Randall R Schulz wrote:

...
On Friday 27 July 2007 17:41, Greg Freemyer wrote: ...

I don't doubt that Oracle (or MySQL or PostgreSQL, etc.) are flexible enough to do this, but that does not mean it's a good idea.

Per a very recent release of Oracle:

What can I say to someone who posts a copy to the list _and_ to the individual... You lose. Ciao. RRS --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org

Randall R Schulz

14:12

On Friday 27 July 2007 19:17, Randall R Schulz wrote:

...

On Friday 27 July 2007 18:48, Greg Freemyer wrote:

...
On 7/27/07, Randall R Schulz wrote:

...
On Friday 27 July 2007 17:41, Greg Freemyer wrote: ...

I don't doubt that Oracle (or MySQL or PostgreSQL, etc.) are flexible enough to do this, but that does not mean it's a good idea.

Per a very recent release of Oracle:

What can I say to someone who posts a copy to the list _and_ to the individual...

You lose.

Ciao.

RRS

Wow. That was really rude. I was upset with something else, and one of my weaknesses is letting my overall emotional state spill over to other matters that come along. The annoyance at getting an off-list copy was enough to trigger it. Sorry. I still disagree about using the root for such things and I wouldn't take recommendations from Oracle that go against my better judgement. Randall Schulz --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org

Greg Freemyer

15:57

On 7/28/07, Randall R Schulz wrote:

...

On Friday 27 July 2007 19:17, Randall R Schulz wrote:

...
On Friday 27 July 2007 18:48, Greg Freemyer wrote:

...
On 7/27/07, Randall R Schulz wrote:

...
On Friday 27 July 2007 17:41, Greg Freemyer wrote: ...

I don't doubt that Oracle (or MySQL or PostgreSQL, etc.) are flexible enough to do this, but that does not mean it's a good idea.

Per a very recent release of Oracle:

What can I say to someone who posts a copy to the list _and_ to the individual...

You lose.

Ciao.

RRS

Wow. That was really rude. I was upset with something else, and one of my weaknesses is letting my overall emotional state spill over to other matters that come along. The annoyance at getting an off-list copy was enough to trigger it.

Sorry.

No problem, I found it more humorous than anything.

...

I still disagree about using the root for such things and I wouldn't take recommendations from Oracle that go against my better judgement.

I actually did some googling for linux mount points and best practice. All I found was the Oracle docs (several, mostly older), and some talking about creating /mnt/hdc1 type of mount points. And opensuse of course uses /media I use those all the time, but for short term mounting, not for long term permanent mounts. And note those too are all on the root partition. I'm almost positive my 15 year old Compaq Tru64 UNIX training recommended putting all long term mount points in the root and I've seen it done by dozens of different customers (ie. situations where I did not make the decisions). I guess in big data centers where you have automated deployment tools it could be a problem to have mount points on the root partition. Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org

Jerry Feldman

19:36

On Sat, 28 Jul 2007 11:57:58 -0400 "Greg Freemyer" wrote:

...

I'm almost positive my 15 year old Compaq Tru64 UNIX training recommended putting all long term mount points in the root and I've seen it done by dozens of different customers (ie. situations where I did not make the decisions).

A great OS (worked as a contractor at Digital for 17 years, 6 in the Unix Development Environment group). Actually, one wants to keep the number of mount points at root down to a minimum. One reason for this is that some software and commands cause a stat command to be run on root and its mount points. -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

Jerry Feldman

13:25

On Fri, 27 Jul 2007 13:20:16 -0700 (PDT) "Curt, WE7U" wrote:

...

On Fri, 27 Jul 2007, Keith Roberts wrote:

...
A standard place to place it would be in /etc, as a text file called yourappname.data, or even under it's own subdirectory, where you could also add a runtime configuration file for your application, called for example, /etc/yourappname/yourapp.conf .

Perhaps stick to the conventions listed in the FHS?

http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

Agreed.. /etc is for configuration files, not data file. If you place a configuration file in /etc, which is appropriate, it could point to where the data file is located. The other issue I did not mention in my post is how are you going to resolve multi-access issues when more than one user is updating the file. There are a number of locking mechanisms available, such as flock(2). -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

opensuse＠sky-bizz.com

23 Aug 23 Aug

18:42

Hi Jerry

...

The other issue I did not mention in my post is how are you going to resolve multi-access issues when more than one user is updating the file. There are a number of locking mechanisms available, such as flock(2).

i am using sqlite3 for storing the data. so i let do the whole work of read/write-synchronizing this great small database engine. kind regards h. hübel --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org

Jerry Feldman

19:55

On Thu, 23 Aug 2007 20:42:59 +0200 opensuse@sky-bizz.com wrote:

...

...
The other issue I did not mention in my post is how are you going to resolve multi-access issues when more than one user is updating the file. There are a number of locking mechanisms available, such as flock(2).

i am using sqlite3 for storing the data. so i let do the whole work of read/write-synchronizing this great small database engine.

That should work. -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

Randall R Schulz

27 Jul 27 Jul

21:17

On Friday 27 July 2007 10:29, opensuse@sky-bizz.com wrote:

...

Hello

[at first: i am not new to developing software, but i am slightly new to developing linux-software :)]

i'm just developing an command line tool for linux (c++), which has to save its data into a single file in the filesystem, undependently from running user. its handling is best described like or compared with "updatedb". there is only one data-file for all users.

in which folder should i create the application's data-file, and whats about the needed rights on it? can this application "ask" for getting needed privileges like on windows?

Your application should be written to use a directory structure of its own referenced only by relative path names combined with a configuration-time or installation-time base directory. It should not assume or have hard coded this base directory. Configuring the application prior to compiling or installing it should supply that base directory. So a complex application might use a directory structure like this: bin/ config/ data/ doc/ In this setup, bin/ would hold the executables and scripts used to launch, configure or maintain the application or subsets of its functionality. Local configuration for the application as a whole would go in config/. Obviously, doc/ would hold documentation files, either those used directly by the application for integrated / on-line help and documentation or for access by end users (maybe a PDF file or something as simple as a READ-ME file). Lastly, data/ would hold the application's pre-supplied or, possibly, locally acquired data. However, in the latter case, creating a directory in /var would probably be better, especially if that data is voluminous. Such a data directory should probably be separately configurable form the installation base directory. In any given build or installation, this cluster of directories might end up in /usr/local/my-app, /usr/local/share/my-app, /opt/my-app or somewhere else.

...

is there a special folder intended for handling such things? if yes, what folder?

kind regards for any help hagen

6092

Age (days ago)

6119

Last active (days ago)

List overview

Download

19 comments

6 participants

participants (6)

Curt, WE7U
Greg Freemyer
Jerry Feldman
Keith Roberts
opensuse＠sky-bizz.com
Randall R Schulz