[[ header START ]]

Welcome to OS2.GURU site! (eComStation.RU)

Select your language: Russian English Deutch Spanish Italian Portuguese Czech Polish French

Frequently asked questions and answers:
telegram

Форум обсуждение

telegram

Send message

telegram

[ +7-981-8529467 (Санкт-Петербург)

telegram

t.me/os2_guru

eComStation.RU


ru · en · de · es · it · pt · cz · pl · fr
OS/2 is a greatly different operating system for PC (ArcaOS, eComStation, IBM OS/2 Warp)
Applications, news, reviews, support of users, hardware, questions and answers.
 
[What is OS/2?  News  Install  Update  
 
 
Usage  Future  Community  Projects  

How to buy
russian OS/2 apps?

The concept of
OS/2 development

(Map of the site)

 
 
[[ head-3-search ]]

Report: OS/2 compatible hardware

[[ head-3-search END ]]

 
Update

 
Applications

 
Advantages:

 
For developer:

 
(Пайпы программ)

 
Companies:

 
History:

 
(Бонусы)

 
Advice:

 
(Барьеры и решения)

 
Technologies:

 
(Применение в науке, лаборатории, ..)

 

 
Solutions

 
New eComStation:

 
Future:

 
(Ссылки на другие сайты)

 
(Картинка дня)

 
OS/2 artefacts:

 
Gadgets:

Upgrade ArcaOS to NeoWPS level

  • Install original PNG icons drawed by designer, specialized at OS/2 adornation.
  • Install eSchemes 2018 to change colors and buttons on desktop.

eCS File and Directory Standard (eFDS)


TITLE: eCS File and Directory Standard (eFDS)

DATE: 2003-08-26 01:19:18

AUTHOR: Nick Morrow

Version 1
2003 May 18
Edited by Nick Morrow
Approved for release by Mensys on 2003 May 18

SUMMARY

This standard consists of a set of requirements and guidelines for file and directory placement under the eCS operating system. The guidelines are intended to support interoperability of applications, system administration tools, development tools, and REXX or batch scripts as well as greater uniformity of documentation. This standard is written with simplicity and ease of use in mind. This document should not be expected to answer all questions at this point as it is a work in progress. You, the eCS user and developer are invited to provide feedback concerning this document. Please contact your eCS supplier with comments concerning this document.

1. Introduction

1.1. Purpose

This standard enables

  • Software to predict the location of installed files and directories, and
  • Users to predict the location of installed files and directories.

We do this by

  • Specifying guiding principles for each area of the filesystem,
  • Specifying the files and directories that are required,
  • Enumerating exceptions to the principles, and
  • Enumerating specific cases where there has been historical conflict.

The document is used by

  • Independent software suppliers to create applications which are eFDS compliant,
  • OS maintainers to maintain eFDS compliance, and
  • Users to understand and maintain the eFDS compliance of a system.

1.2. Conventions

Components that vary are represented by a description of the contents enclosed in "<" and ">" characters.

Optional components are enclosed in "[" and "]" characters and may be combined with the "<" and ">" convention.

Variable substrings of directory names and filenames are indicated by "*".

2. The Filesystem

It is possible to define two independent categories of files: shareable vs unshareable and variable vs static. There is a simple and easily understandable logic to understanding the reason for defining these categories:

Why are we separating directories into shareable and nonshareable?

Primarily for ease of administration. If a system administrator must search many locations in the file system because of a lack of clear guidelines or adherance to guidelines then a lot of time is wasted and the effort is more pron to errors.

Why are we separating directories into variable and static?

We need to take into consideration which directories should be read-only and which should be read-write. Static directories should be read only except to the system administrator while variable directories should be read-write for more users than the system administrator.

Shareable files are those which can be shared between different hosts.

Unshareable files are those which are specific to a particular host.

Static files consist of files that do not change without system administrator intervention. Examples include binaries, libraries, and documentation.

Variable files consist of files that do change without system administrator intervention. Examples include data files.

  • In a networked environment (i.e., more than one host at a site), there is a good deal of data that can be shared between different hosts to save space and ease the task of maintenance. If shareable files are grouped together in a logical manner a significant reduction in administrator workload can be realized.
  • In a networked environment, certain files contain information specific to a single host. Therefore these filesystems cannot be shared (without taking special measures).
  • Interspersing shareable and unshareable data in the same hierarchy makes it difficult to share large portions of the filesystem.
  • Interspersing variable and static data in the same hierarchy makes it difficult to implement a data backup plan.

Summarizing chart:

Note: eCS will contain the following minimum directories to meet eFDS-1 guidelines. Additional root directories will be needed and used on current releases of eCS due to the requirements of the supporting OS/2 operating system. The goal is to consistantly reduce until finally eliminating all directories not listed below.

shareable unshareable
static \programs \ecs, \etc
variable \home \var, \etc

  • \ecs
    - similar to root (/) in Linux
    - static, nonshareable files
    • read-only
    • will not be made available on the lan
    • must be located on host system
    • must be on the boot volume
    • must be one instance and no more on host system
  • \etc
    - similar to /etc in Linux
    - variable and static, nonshareable files
    • read-write
    • will not be made available on the lan
    • must be located on host system
    • must be on the boot volume
    • contains variable and static data requiring backup
  • \home
    - similar to /home in Linux
    - variable, shareable files
    • read-write
    • may be made available on the lan
    • does not need to be located on the host system
    • does not need to be on the boot volume
    • may be more than one instance on host system
    • contains variable data requiring backup
  • \programs
    - similar to /usr in Linux
    - static, shareable files
    • read-only
    • may be made available on the lan
    • does not need to be located on the host system
    • does not need to be on the boot volume
    • may be more than one instance on host system
  • \var
    - similar to /var in Linux
    - variable, nonshareable files
    • read-write
    • will not be made available on the lan
    • must be located on host system
    • does not need to be on the boot volume
    • must be one instance and no more on host system

Note: While there are similarities to the directory system in Linux one should not view this to mean that eCS is a re-implementation of Linux. eCS will implement a file and directory structure that best meets the needs of users and developers.

3. The Boot Volume

3.1 Purpose

The contents of the boot volume must be adequate to boot, restore, recover, and/or repair the system.

  • To boot a system, enough must be present on the boot volume to mount other filesystems. This includes utilities to modify, move and delete files in order to restore a satisfactory configuration. Required system utilities shall be contained in the appropriate directories in \ecs (or for now in \OS2). \ecs must be located on the boot volume on the host system. \home and \programs are designed such that they may be located on volumes other than the boot volume and may, in fact, be located on systems in the network other that the host system. \var is not required to be located on the boot volume but it must be located on the host system as the data contained in /var is non-shareable.

The primary concern used to balance these considerations, which favor placing many things on the boot volume, is the goal of keeping boot volume as small as reasonably possible. For several reasons, it is desirable to keep the boot volume small:

  • The boot volume contains many system-specific configuration files. This means that the boot volume isn't always shareable between networked systems. Keeping it small on servers in networked systems minimizes the amount of lost space for areas of unshareable files. It also allows workstations with smaller local hard drives.
  • Disk errors that corrupt data on the boot volume are a greater problem than errors on any other partition. A small root filesystem is less prone to corruption as the result of a system crash.
  • Smaller boot volumes permit greater flexibility in system setup and maintenance to include the use of bootable memory disks, remote boot volumes, and "universal" boot volumes customised to fit a particular line of identical systems.

Software must never create or require files or subdirectories in the root directory. Other locations in the eFDS hierarchy provide more than enough flexibility for any package.

There are several reasons why introducing a new subdirectory in the root directory is prohibited:

  • It demands space on a root partition which the system administrator may want kept small and simple for either performance or security reasons.
  • It evades whatever discipline the system administrator may have set up for distributing standard file hierarchies across mountable volumes.

3.2 Requirements

The following directories are required to meet eFDS standards:

  • \ecs operating system related directories - unshareable static files
  • \etc variable data files - unshareable variable and static files
  • \home user home directories - shareable variable files
  • \programs application directories - shareable static files
  • \var variable data files - unshareable variable files

3.3 Specific Options

The \ecs directory shall contain the following directories:

  • \ecs\bin essential command binaries (no subdirectories allowed)
  • \ecs\book .inf files
  • \ecs\boot device drivers
  • \ecs\dll essential shared libraries
  • \ecs\doc documentation files (contains only subdirectories)
  • \ecs\help .hlp files
  • \ecs\install installation files (contains subdirectories)
  • \ecs\lang national language support
  • \ecs\system essential system binaries (contains only subdirectories)

NOTE: \ecs\bin and \ecs\system both contain essential binaries but they are for very different purposes. \ecs\system contains only directories that hold files related to large complex packages, while \ecs\bin is for standalone system utilities. There is no implied GUI/CLI split; a CLI ini file editor and backup program can be a large complex package which should be located in \ecs\system, while a GUI volume manager could be a standalone binary located in \ecs\bin.

The \etc directory shall contain the following directories:

  • \etc\log system and non-user specific application log files

    Note: This is a chance since the release of eCS v1.1 which has the log file directory located as such: \var\log

The \programs directory shall contain only subdirectories which in turn will contain the files and subdirectories specific to a particular application. As an example:

  • \programs\browser would contain the static executable files required to run an internet browser.

The \home directory shall contain only subdirectories which in turn will contain the files and subdirectories specific to a particular user. As an example:

  • \home\\ would contain the directories which contain variable configuration and data files created, owned and maintained by . Another to view this directory is that if needs to back up his/her work then this is the only directory he/she should need to back up.

The \var directory shall contain the following directories:

  • \var\cache intended for cached data from applications. Such data is locally generated as a result of time-consuming I/O or calculation. The application must be able to regenerate or restore the data. Unlike /var/spool, the cached files can be deleted without data loss. The data must remain valid between invocations of the application and rebooting the system.
  • \var\spool contains data which is awaiting some kind of later processing. Data in \var\spool represents work to be done in the future (by a program, user, or administrator); often data is deleted after it has been processed.
  • \var\temp temporary files and directories

Each directory listed above is specified in detail in separate subsections below.

3.4 \ecs\bin : Essential user command binaries (for use by all users)

3.4.1 Purpose

\ecs\bin contains commands that may be used by both the system administrator and by users. It may also contain commands which are used indirectly by scripts or batch files.

3.4.2 Requirements

There must be no subdirectories in \ecs\bin.

\ecs\bin must be included in the SET PATH statement in CONFIG.SYS.

The following commands are required in \ecs\bin.

  • cpu.exe Utility to report the number of processors installed
  • mem.exe Utility to report the amount of memory installed
  • unzip.exe The unzip unarchiving utility
  • zip.exe The zip archiving utility

Note: This list needs to be updated prior to the next release of this document.

The requirement for a minumum set of system utilities to perform various maintenance and troubleshooting functions is vital to the capability to keep the system operating as desired.

3.5 ecs\boot : Static device driver files

3.5.1 Purpose

This directory contains device drivers with the exception of device drivers that must be located elsewhere such as BASEDEV drivers which must be located in "\" or "\os2\boot" in current releases of eCS.

3.5.2 Requirements

Device driver loading:

A clean boot is desirable. Default driver operation will be Quiet mode (/Q).

There are three situations where a driver may temporarily pause the boot process and/or post a message:

  1. If registration is pending.
  2. If the driver detects a problem during boot and needs to post a warning or error message.
  3. If the user tells the driver to post information by adding the /V (Verbose) parameter to the driver in the config.sys file.

4. CONFIG.SYS : Host-specific system configuration

4.1 Purpose

CONFIG.SYS contains much of the basic configuration information that is specific to a system. It is necessary that we define certain mandatory entries:

SET ETC=X:\etc SET ETC sets the environment variable ETC so that programs and utilities may determine the directory to be used for variable and static system configuration files.
SET TMP=X:\var\temp
SET TEMP=X:\var\temp
SET TMP and SET TEMP set environment variables so that programs and utility may determine the directory to be used for temporary files.
SET HOME=X:\home\ SET HOME sets the environment variable HOME so that programs and utilities may determine the directory which is currently designated as the HOME directory.
SET PROGRAMS=X:\programs SET PROGRAMS sets the environment variable PROGRAMS so that programs, utilities and software installers may determine the directory which is designated as the directory where all non-system programs and utilities should be installed.
SET LOGFILES=X:\etc\log SET LOGFILES sets the environment variable LOGFILES so that programs, utilities and software installers may determine the directory which is designated as the directory where all log files should be stored. utilities should be installed.

It is also necessary that we define certain programming guidelines:

  • Programs/utilities that create log files should check to see if LOGFILES is set and use it if it is. If LOGFILES is not set or the directory doesn't exist then log files should not be created. Log file names should follow this example:
        .log - estyler.log
        
  • Programs/utilities that use ini files to store user specific configuration information should check SET USER_INI= and use this directory to store ini files. Ini files should follow this example:
        .ini - estyler.ini 
        

    An example of the location: SET USER_INI=x:\home\stjohnb\etc\user.ini

    eStyler would then locate estyler.ini as such: x:\home\stjohnb\etc\estyler.ini

  • Programs/utilities that use ini files to store system wide configuration information should check SET SYSTEM_INI= and use this directory to store ini files. Ini files should follow this example:
        .ini - estyler.ini 
        

    An example of the location: SET SYSTEM_INI=X:\etc\system.ini

    eStyler would then locate estyler.ini as such: X:\etc\estyler.ini

  • Programs/utilities should always check to see if their ini exists and if it doesn't exist then a new one with reasonable defaults should be created. INI files should be standard OS/2 style binary INI files.
  • Programs/utilities should not make modifications to CONFIG.SYS with the exception of adding required device drivers nor should they use the user.ini or system.ini to store settings.

Additional information:


Test the program:

Secure work in eComStation: reviews, tools and recommendations

Comments:

samm
2003-08-26 19:34:02

&#1055;&#1086;&#1087;&#1099;&#1090;&#1082;&#1080; &#1089;&#1076;&#1077;&#1083;&#1072;&#1090;&#1100; &#1080;&#1079; &#1086;&#1089;&#1080; &#1085;&#1077;&#1076;&#1086;&#1102;&#1085;&#1080;&#1082;&#1089; &#1074;&#1099;&#1075;&#1083;&#1103;&#1076;&#1103;&#1090; &#1082;&#1088;&#1072;&#1081;&#1085;&#1077; &#1089;&#1084;&#1077;&#1096;&#1085;&#1086;..

Yuri Prokushev
2003-08-26 20:11:13

...., ...-.... ... .... .... ........ ............

Eugene Gorbunoff
2003-08-26 20:28:39

Yuri Prokushev: . ..... ..... . .... ......... .... .. ........? .. ....... .... .. ........... ..... eCS ... ... ..... ......, ... . ibm'...... OS/2. ......., ... ..... ....... *.. .........*..

........... ...... ..... ....., ... ....... ...... ............, ... ............. .... ....... .. ......... ............ . .... - ... ... ....... .. ..... .... .............. ...... .............. ............ ......., . ........... .. .... ....... ...

Evgen
2003-08-26 22:24:29

What about compatibility with

\os2

\mptn\etc

etc. ?

...........
2003-08-26 22:30:11

.. ..., ......... ... .... ........ .. ......... ........... . .. .. ..... ...... ........ ..... ............ . ........... ........... .. ......... ......... ......... (unixos2 project, etc). ........., ... ....... . ...... ... .............

. ...... ........... ..... ... ...... ....... .. ........, ... ..... . .... .......... . ......... ... ... .... ......, ......... .... ......... ;)

Yuri Prokushev
2003-08-26 22:40:17

2Eugene Gorbunoff: ....., ... .. ........ .., ... . _......_ ........ ....... . .:\ecs, . .. d:\hachu_tak.. ... .. ........ .. .. . ... ........ var. .. .. .... . .. ....... .. ....... ....... . ....

... ..., ... ........

. ... .. ....... .... . ....... unixos2? ... .... .... .... var/etc/home. ....... . ............ .... . .......

"........" ...... ......

Yuri Prokushev
2003-08-26 22:41:20

..., ......, ... ... ......, .... . .... ............ .......... ..... ... ...... ......? ..... ........ .... ......?

Nicky Morrow
2003-08-27 10:32:02

2 Evgen: Since eCS uses the OS/2 kernel and much of the current OS/2 distribution as its core we must retain many of the existing OS/2 directories for now. As time passes the intention is to eliminate many of the OS/2 directories so as to simplify the directory structure. The \OS2 directory cannot be removed currently and may not be removed for a long time due to hardcoding in current editions of the OS/2 kernel. The current shipping v1.1en still contains \OS2 as well as \ecs. No compatibility problems have been noted. Concerning \MPTN\ETC: Adding SET ETC=X:\ETC to config.sys as noted in eFDS-1 has not been emplemented in eCS yet. If you see any potential problems please bring them to our attention and we'll address the issue.

2 Yuri Prokushev:

> 1) I don't want hold eCS directories on boot drive.

eFDS only requires that 2 os related directories be on the boot volume: \ecs and \etc. Both of these directories are critical system directories that can reduce the functionality of the system or totally prevent the system from operating correctly if the kernel is unable to access them. If these directories could be placed on alternate volumes which could be on alternate drives then you are now look at a situation where a failure in either of two drives can take your system totally out whereas if they are located on the boot volume then the system with still be functional unless the drive the os is on goes out. I'd be interested in the specific reasons why you don't want these 2 directories on the boot drive.

>I don't like that i am obligated to place system files in c:\ecs, can I place system files in d:\hachu_tak ?

You can manually but a good argument can be made that consistancy in certain areas is more advantageous than flexibility.

>(and don't like the same situation with var directory)

I don't follow this. Please be specific.

> 2) What about compatibility with unixos2 project? This subsystem uses var/etc/home directory too.

Over a period of months last year I subscribed to the unixos2 newsgroup specifically to try to ensure there were no conflicts. I have used all of the input from this group that they made available to me. Compatibility should be good. If you have specific situations please bring them to my attention so they can be tested.

> 3) IMHO, the standard seems "raw"

It is "raw." It is very hard to find time to code and document. I'm taking time away from coding to help in the documentation. I currently have several documents in progress. This document so far contains issues that have needed to be addressed internally. Programmers and users are very welcome to submit additional items they feel should be included. The document needs to grow and mature.

> 4) I have created an application and want install help files on different languages. Where to place this help files? I don't see instructions in this standard.

I'll research the issue and get back to you. The answer to this should be in this document.

Andrew Belov
2003-08-27 13:22:39

It would be advantageous if separate directories for "miscellaneous" executables and "shared" 3rd-party libraries are stipulated. That is, we need to tell /bin (\OS2) from /usr/bin (e.g. \Programs\BIN), and /lib (\OS2\DLL) from /usr/lib (\Programs\DLL).

What has to be "shared"? Archivers, stand-alone 3rd-party utilities (like GO.EXE), and command-line utility sets are not worth wasting separate directories for them. The user may decide to dump them into \Programs\BIN (or whatever); but it's better this location is standardized so installers can benefit too.

The "shared" DLLs are good for exactly the same reason: to prevent pollution of \OS2\DLL; to facilitate backups and after all, they are helpful if multiple versions of OS/2 coexist on the same PC. On the system I'm typing this from, there is a similar directory that hosts the OpenGL runtime, VROBJ.DLL, VAC runtimes, NCurses DLL, OpenSSL DLLs, etc. - totaling 121 files.

Overall, the specification looks promising. If \MPTN, \IBMCOM, \IBMLAN, \MUGLIB and other "obstacles" are taken out from the root directory, personally I would call the eCS installer a success.

Yuri Prokushev
2003-08-27 13:44:02

>> 1) I don't want hold eCS directories on boot drive.
>eFDS only requires that 2 os related directories be on the boot volume: \ecs and \etc.
Do you mean \var? \etc controlled by ETC envar

>I'd be interested in the specific reasons why you don't want these 2 directories on the boot drive.
Ok. Let's talk about \var. I don't see any reason to have \var hardcoded. Let's imagine following situation: I have some software installed with lot of log output. Having \var directory on boot partition requires or use some scripts to reduce log size (aka additional resources usage) or make boot partition bigger. Same situation with huge temporary files. With \var at boot partition I can easely have problems with free space. According \ecs. Having system files hardcoded opens gateway for destructive programs. It's can be security issue. Another issue is possibility to have boot volume as small as possible.

>>I don't like that i am obligated to place system files in c:\ecs, can I place system files in d:\hachu_tak ?
>You can manually but a good argument can be made that consistancy in certain areas is more advantageous than flexibility.
Well, I understand you can't change os2krnl much (instead of binary patching), But I'm prefer to have control over whole system, not only parts of them.

>>(and don't like the same situation with var directory)
>I don't follow this. Please be specific.
Most probably, you must think about \var, not \etc ;)

>Over a period of months last year I subscribed to the unixos2 newsgroup specifically to try to ensure there were no conflicts.
Yes, I seen.

>I have used all of the input from this group that they made available to me. Compatibility should be good. If you have specific situations please bring them to my attention so they can be tested.
None yet.

> The document needs to grow and mature.
Well. Then having mark DRAFT will be good answer for lot of questions.

>> 4) I have created an application and want install help files on different languages. Where to place this help files? I don't see instructions in this standard.
>I'll research the issue and get back to you. The answer to this should be in this document.
Really, at the present time we have many various 'standards' about support of national languages. None of them are complete. I know only two standards for messages. It is original OS/2 *.MSG files and *nix gettext.

Isaac Leung
2003-08-27 23:53:16

Let me first say that I'm glad this initiative is taking place. A standardized file structure is a Good Thing, in my opinion.

I have some comments about the document just released:

(BTW, I am not a computer newbie. It's my "job" and I've been at this from C64 to mainframes for something like 18 years now)

=> \etc and \var : Why? We are not trying to emulate Linux/UNIX. These names are meaningless to most average users, and we have the capability to use more than 3 letters for directories! Please, PLEASE consider getting rid of this.

If you are looking for some sort of *NIX/Linux compatibility, let these exist as an option.

Have a look at what OS X does. Even though these directories exist (for compatibilty), they are "pointed" at by a more meaningful name.

We don't have a soft-link option (do we?) and we don't need compatibility so let's make the system USER friendly. As in a common computer user, not a computer science guy.

Samm
2003-08-28 01:16:20

i think that we dont need such system. One of the main os2 benefits is possibility to realy fast move programs from one locaion (or os) to another. because all is in one directory. If log will be in var/log and ini in other dir we well have many garbage . BTW, why not to leave os2 directory structure as is ? Only because c00l ecs huackers (which even have no sources, hehe) want to do smth. ? Better think about PM problems, or try to port openoffice. I think, that changing tree is very stupid time spending....

Kirov Igor
2003-08-28 07:52:17

......... ...... - ..... ..... .... ........ ........ ..........? ... .. ..... ............ . ANSI ... ISO? ...... ...... .... ....... ............?

Matt Bear
2003-08-28 08:39:03

>3.3 Specific Options

>The \ecs directory shall contain the following directories:

[cut to save space]

>* \ecs\book .inf files

*> \ecs\doc documentation files (contains only subdirectories)

>* \ecs\help .hlp files

[cut to save space]

Having three different subdirectories for documentation in different formats strikes me as strange. Is there a compelling reason to seperate the content this way instead of creating a single directory?

>We don't have a soft-link option (do we?)

Could TVFS provide the soft-link capability?

Dave Saville
2003-08-28 10:35:44

Log files: What about the style of logfile that includes the date? Some programs produce logfiles of the form yyyddmmhhmmss.log in their own dir and keep several versions. What about using *nix style cycle log programs that produce prog.log, prog.log.1 prog.log.2 prog.log.3.Z etc.? ie they keep n generations, m of which are compressed. Some programs can produce *huge* log files - having log in .etc which is tied to the boot volume conflicts with trying to keep the boot volume small. The original of /var /log is much more sensible. Think of a server rather than a workstation that is up 24*7 OK I know ECS is supposed to be a workstation but with nothing else available people are going to use it for a server - I will be.

Nicky Morrow
2003-08-28 10:44:52

2 Andrew Belov:

>The "shared" DLLs are good for exactly the same reason: to prevent pollution of \OS2\DLL;

Adding \programs\bin and \programs\dll is a good idea. Two things come to mind:

1) ..\bin will need to be added to the PATH and ..\dll will need to be added to the LIBPATH. It would be good to be reducing the size of the PATH and LIBPATH statements instead of growing them. Do you see any offsetting ways to reduce the sizes?

2) What about \programs\help? See the \ecs\ directory structure: We need to be consistant.

>Overall, the specification looks promising. If \MPTN, \IBMCOM, \IBMLAN, \MUGLIB and other "obstacles" are taken out from the root directory, personally I would call the eCS installer a success.

I'm pushing as hard as I can to convince the administration at Serenity that this needs to happen soonest.

2 Isaac Leung:

> Let me first say that I'm glad this initiative is taking place. A standardized file structure is a Good Thing, in my opinion.

I agree. Hopefully we are headed in the right direction.

>(BTW, I am not a computer newbie. It's my "job" and I've been at this from C64 to mainframes for something like 18 years now)

Good. Then we can count on you to sent additional items that need to be included in the document :)

>=> \etc and \var : Why? We are not trying to emulate Linux/UNIX.

It is true that we are not trying to emulate Linux/Unix. \var has been implemented in eCS v1.1en but with a very convincing case it could be changed. \etc is a more recent edition to eFDS and is not yet included in eFDS. I welcome your suggestions and reasoning behind the suggestions.

>Have a look at what OS X does. Even though these directories exist (for compatibilty), they are "pointed" at by a more meaningful name.

I have never seen OS X nor do I have access to a box running OS X. Please explain.

>We don't have a soft-link option (do we?) and we don't need compatibility so let's make the system USER friendly.

I understand. Actually a lot of what is going on here is to make things better for the user and sysadmin. That is not to say that we are doing a good job in all areas. Like I said above, please spell out the better way. I am simply the editor of the document. If I am given a better idea and a good justification it will make it easy for me to get approval for the change or addition from the eCS DevGroup.

2 Samm:

I can understand the desire not to change the exiting OS/2 directory structure, however, the current structure does not serve us well as far as where the operating system must go in order to stay competitive. In order to add capabilities such as multi-user or reduce the sysadmin burden we must have a more orderly file and directory system. Mixing applications, application data, configuration files and system files is a very poor practice and makes the product more difficult to sell and use.

In regards to your statement about locating log files and ini files in specific locations: I submit that this is a very very good practice that will enhance usability and maintainabily.

Andrew Belov
2003-08-28 12:41:14

To Nicky Morrow:

(1) comprises a solution by itself. Without \programs\bin, we would expect a bunch of scattered directories like \programs\cdutils\bin, \programs\archivers\bin, etc.; which are effectively eliminated by a proposed "common" path. Same for DLLs.

(2) is definitely required if we expect PM utilities to be there, and for *.MSG, if any. Can't estimate if we need a separate directory, though. On my system, I see very little utilities using a *.HLP/*.MSG file, so I've ended up placing them altogether into \programs\bin, so that \programs\bin is among %HELP%.

samm
2003-08-28 17:21:11

I think that any user can change OS/2 fs structure as he want (using path, libpath end dpath).

Multiuser support can be perfectly added without this (see SSES project). I think, that directory structure is not real problem of os/2. Better try to rewrite PM, heh ;-)

P.S. Webmaster of this c00l site denied acces to my ip ;) (heh, anonimous proxies are so slowwww).

Thorolf
2003-08-29 01:37:36

Sorry, but not OK at all!

- /ecs seems to be the same as the /os2-directory - do you want to make eCS-apps incompatible to OS/2????

- /etc on Linux is or settings, not for any changing data so for logs the wrong place - put it to /var/log (as in Linux)!

Nicky Morrow
2003-08-30 14:04:04

2 Kirov Igor:

The document is an effort to bring efficiency into the operating system by establishing standards or normal methods in several areas where standards have either not been identified by IBM or the methods identified are poor or outdated.

2 Matt Bear:

> Having three different subdirectories for documentation in different formats strikes me as strange. Is there a compelling reason to seperate the content this way instead of creating a single directory?

There was a long detailed discussion about this area amoung the members of the eCS DevGroup last year and this was what was decided at the time. The members of the group can be very flexible if somebody comes along with a better idea so please tell me how you would do it and why.

> We don't have a soft-link option (do we?)

Not that I'm aware of. Do we need one?

2 Dave Saville:

> What about the style of logfile that includes the date?

I see your point. Give me a chance to rehash this issue as I can't find the info on why the change was made right now.

> The original of /var/log is much more sensible.

Let me get back to you on this issue.

2 Thorolf:

> do you want to make eCS-apps incompatible to OS/2????

I don't understand this statement.

> /etc on Linux is for settings, not for any changing data

Settings can be in changing (variable) data files...see system.ini and user.ini as examples.

> so for logs the wrong place - put it to /var/log (as in Linux)!

I'll relook this issue. Thanks for the input.

Stefan Milcke
2003-08-30 14:55:41

I totally disagree with this "standard". I think we don't need such system. Please don't rename/replace old directories with this standard. I'm using and developing for OS/2 for a long time and i don't want a "new directory structure". This makes live difficult for "OS/2 Gurus".

MfG Stefan Milcke

42 ;-)

Andreas Schnellbacher
2003-08-31 04:17:48

Hi Nick,

creating a general dir standard is a really important thing. I concidered much about the TeX DS and before shipping NEPMD 1.00, we made a lot of considerations, too.

In details:

OS/2 program packages are different from Linux things: E.g. for the SuSE TeX dist, I hate it to have one config file 3 times on disk, not knowing which one counts. I hope, we 're not going to port this to eCS. For many existing OS/2 apps it's not possible to fit them in a Unix-like dir standard (e.g. because their development has stopped.)

So, we have to make the dir standard more flexible. I know, that current apps don't fit multi user envs. But instead of making those apps unable to be used anymore, we should find a flexible way. I know, this sucks, because it's not easy to find a standard at all. But we need a way to integrate most of the common apps (that are _not_ developed any further) and apps with current releases, where the develepor should meet the multi-user affords.

Here's the problem, I see (a 'fast shoot') with the NEPMD env.: There are many config files. The 'MYEPM' dir maybe consist only of configs. They are not subdivided according to system or user, because the main goal of our NEPMD dir standard is to fit for multiple users, not to distinguish between systems and user settings. (Almost everything is a user setting.)

I think the TeX DS might be a good example to get this goal while being flexible. In your planning you have no flexibility (but I agree with almost all your thoughts). We need flexibility, because current apps are not designed to fit into a Unix-like structure nor to a LAN env. Sorry, no more details so far.

Hendrik
2003-08-31 14:35:28

- too much Linux

- too rigid

- the files of a program package would be too scattered

- The OS and the applications would inevitable mixed

So burn this paper, bury it and forget it !

What a total waste of time !!!

Nicky Morrow
2003-08-31 21:28:44

2 Hendrik:

> too much Linux, too rigid

What would you change? Please be specific. Any particular developer can choose whatever road he/she wants to travel as the flexibility is there, however, if said developer wants to advertise "eFDS compliant" then he/she should follow the guidance in this document.

> the files of a program package would be too scattered

For a end user application package eFDS provides one place for the application files to go:

\programs\<myapp>

How is it that this is going to scatter files?

> The OS and the applications would inevitable mixed

I don't follow this statement. See above answer.

2 Stefan Milcke:

> I totally disagree with this "standard".

I've been using and developing for OS/2 since v1.3 myself. Please understand that this document is not a one person creation but rather a document that contains ideas from many in the development community. I have acted as editor. Some ideas are mine but most have been taken from others. There are at least a couple of items in the document that I don't care for but am willing to tollerate in the interest of having a standard. Please tell me specifically what you feel should be changed or added.

>and i don't want a "new directory structure". This makes live difficult for "OS/2 Gurus".

We can just agree to disagree on this point. Much of this standard is already in eCS v1.1en and I am not seeing any developer complaints so far.

Stefan Milcke
2003-08-31 23:31:18

> I've been using and developing for OS/2

> since v1.3 myself. Please understand

> that this document is not a one person

> creation but rather a document that contains

> ideas from many in the development community.

> I have acted as editor. Some ideas are mine

> but most have been taken from others. There

> are at least a couple of items in the document

> that I don't care for but am willing to

> tollerate in the interest of having a standard.

> Please tell me specifically what you feel

> should be changed or added.

Nothing should be added.

If you plan to replace/move \OS2, \MMOS2, \TCPIP, \MPTN etc. then please

think of all old installtions that are incompatible with this standard.

Not all old machines with Warp 3 or Warp 4 will be updated to eCS. I've two

machines with OS/2 here. One is for remote debugging device drivers and it's

at the level of Warp 4. The other machine is eCS. Working on two machines

can be confusing (where to search for device drivers, etc.) And because the

\OS2 directory is hardcoded in the kernel it is difficult to get the newest

release from testcase.

So if you really plan to replace/move these directories please let it be!

Your "Standard" is good for new applications, but not for the system.

>> and i don't want a "new directory structure".

>> This makes live difficult for "OS/2 Gurus".

> We can just agree to disagree on this point.

> Much of this standard is already in eCS v1.1en

Oh. Nice to hear this. I've already ordered 1.1DE. I think i should stop

this order or find a way to reintroduce the old directory structure.

MfG Stefan Milcke

42 ;-)

Eugene Gorbunoff
2003-09-01 03:03:36

2 Stefan Milcke:

1) Your main argument - you care about compatibility with OS/2 machines in neighbourhood. Please, don't worry! eCS doesn't limit OS/2 user. Remember, that IBM OS/2 Warp was developed many years ago .. then there was a long pause.. Now the dynamics of operating system development increase and old structure doesn't correspond to current requirements of OS producer, independent developers and users. Example: old Warp3 notebook became obsolete in 1996 so Merlin was equipped with more flexible "Lotus" notebook ready to hold dosenz of pages. The functionality of old notebook was preserved (press RMB and you see tabs of old notebook).

Every eCS standard follows the same way: OS/2 developer may use the standard OS/2 structure, but If he is interested to embed his product to eCS and care about users from different countries and from different OSes then he can do this because eFDS document describes all necessary aspects: where to keep language specific stuff, where to keep user's data, etc.

I see a nice positive opportunity for BTTV subsystem! I am confused now, where to keep user's data? Imagine that I am going install new version of OS and update old software (I have old stable FileCommander, old stable BTTV, old stable cdrtools, etc). What I have to do? copy hundreds of .ini, .cfg files from the directories to temporal dir then move this files back? As I understand, eCS offers keep user's data in one place. *Every* user knows that all his custom data is located in directory ABC on disk X: There are many other simple but visual advantages of eCS.

2) The second argument - "This makes live difficult for OS/2 Gurus". You don't have troubles here.. Every guru goes to URL with eFDS standard and immediately finds necessary information. You are right, it's difficult research and accumulate OS/2 tips.. eCS team cares about you - all changes are documented and will be published.

3) Don't stop your order else eComStation.Ru will be charged as anti-eCS site :) You have came into contact with eCS developers.. and you have power to adjust changes or indicate danger. Nicky Morrow mentioned that eCS 1.1 was tested to compatibility with different subsystems and don't forget that eCS uses OS/2 Warp components. eCS is unable to break peace os OS/2 users - imagine that thousands of eCS users have installed new incompatible/incomprehensible/uncontrollable version of OS! The Earth planet will fall off from axis! :)

Nicky Morrow
2003-09-01 11:51:03

2 Andreas Schnellbacher:

>creating a general dir standard is a really important thing.

Yes, I think so too.

It appears that this document is giving the impression to some that it will break backward compatibility. This is not the idea at all. If an OS/2 developer wants to continue coding exactly like he/she has done for years, he/she should have no problems with eCS maintaining OS/2 compatibility. If, on the other hand, developers want to step up to a higher standard that should make the os simplier and easier to maintain and trouble shoot then they should code in accordance with eFDS and advertise that their proggy is eFDS compliant.

>So, we have to make the dir standard more flexible.

I hear you. Make specific recommendations and we'll hash out whether they should be included in eFDS.

>We need flexibility, because current apps are not designed to fit into a Unix-like structure nor to a LAN env.

I understand. As you have time to ponder and develop ideas please let me know.

2 Stefan Milcke:

The change in the traditional OS/2 directory structure is going to be very slow as we must extensively test for compatibility issues. Example: For the next release of eCS (the one after v1.1) there are currently only 3 changes being considered and scheduled for testing:

- Move: \SDD to \programs\SDD

- Delete: \IBMVESA

- Move: \SPOOL to \var\spool

I think this should show just how much care is being taken. Do you see problems with these changes? Progress will be made but not at the expense of creating chaos.

Andrew Belov
2003-09-01 12:38:18

To Nicky Morrow: you are exceedingly cautious. :-)

The SDD executables can rest anywhere on the system - it has no path dependencies built in.

\IBMVESA was only required for WD90C24 (the famous VLB "Windows Accelerator" video card from 1993), and it surely can be placed anywhere as well. But better if it gets purged.

Can't comment on the \SPOOL issue right now (seems to be detachable too).

However, I strongly encourage to take the issue of \MPTN, \IBMCOM, \IBMLAN and \MUGLIB into consideration for the next release of eCS, as more time will get wasted on testing the things incrementally, and from my personal view, eCS v 1.1 is already behind its schedule.

Stefan Milcke
2003-09-01 12:38:51

2 Eugene Gorbunoff

> 1) Your main argument - you care about compatibility with OS/2

> machines in neighbourhood. Please, don't worry! eCS doesn't limit

> OS/2 user. Remember, that IBM OS/2 Warp was developed many years

> ago .. then there was a long pause.. Now the dynamics of operating

> system development increase and old structure doesn't correspond to

> current requirements of OS producer, independent developers and users.

> Example: old Warp3 notebook became obsolete in 1996 so Merlin was

> equipped with more flexible "Lotus" notebook ready to hold dosenz

> of pages. The functionality of old notebook was preserved (press RMB

> and you see tabs of old notebook).

> Every eCS standard follows the same way: OS/2 developer may use the

> standard OS/2 structure, but If he is interested to embed his product

> to eCS and care about users from different countries and from different

> OSes then he can do this because eFDS document describes all necessary

> aspects: where to keep language specific stuff, where to keep user's

> data, etc. I see a nice positive opportunity for BTTV subsystem! I am

> confused now, where to keep user's data? Imagine that I am going install

> new version of OS and update old software (I have old stable FileCommander,

> old stable BTTV, old stable cdrtools, etc). What I have to do? copy hundreds

> of .ini, .cfg files from the directories to temporal dir then move this

> files back? As I understand, eCS offers keep user's data in one place.

> *Every* user knows that all his custom data is located in directory ABC on

> disk X: There are many other simple but visual advantages of eCS.

**************************

This is all true. But only at application level, not at operating system level.

Nicky Morrow wrote "As time passes the intention is to eliminate many of the OS/2 directories so as to simplify the directory structure.". And this is the reason why i disagree with this "standard". Why looking for BASEDEV's in \ECS\BOOT on one machine and in \OS2\BOOT on an other machine? Why change contents of \MMOS2, \TCPIP, etc?

BTTV stores it's INI's where all MMOS2's INI files are stored: in \MMOS2.

So a better way is to document the status quo for the OS and define this standard for applikation level.

> 2) The second argument - "This makes live difficult for OS/2 Gurus". You

> don't have troubles here.. Every guru goes to URL with eFDS standard and

> immediately finds necessary information. You are right, it's difficult

> research and accumulate OS/2 tips.. eCS team cares about you - all changes

> are documented and will be published.

**************************

Nice. Looking for a file in \OS2. It doesn't exist. So search in \ECS. And vice versa. Well, there are documents about this, but you have to know...

This is "trouble"!

> 3) Don't stop your order else eComStation.Ru will be charged as anti-eCS site :)

> You have came into contact with eCS developers.. and you have power to adjust

> changes or indicate danger. Nicky Morrow mentioned that eCS 1.1 was tested to

> compatibility with different subsystems and don't forget that eCS uses OS/2 Warp

> components. eCS is unable to break peace os OS/2 users - imagine that thousands

> of eCS users have installed new incompatible/incomprehensible/uncontrollable

> version of OS! The Earth planet will fall off from axis! :)

**************************

Please keep in mind what Nicky Morrow wrote: "As time passes the intention is to eliminate many of the OS/2 directories so as to simplify the directory structure."

This will break something.

MfG Stefan Milcke

42 ;-)

Richard Gelderblom
2003-09-02 16:23:49

Hi all,

This is my shot at a standardized tree.

My reasoning is this : have a flexible yet easy to adapt setup, not leaning on legacy

setups like *nix.

It might be a bit technical setup but OTOH you can find stuff easily and strip anything

out for a super-slim setup without having to worry about dozens of files floating about

of which you don't know what they're doing.

Also for maintaining more identical machines the \dev is what will make the difference

between them since the rest is fairly independent of that (ok a CDFS is useless if you

don't have a cd-drive in a particular machine...).

Fixes and updates can be done by using xcopy of a (partial) tree.

I know that a couple of things might not work right now since things are hardcoded

(like \os2\boot to find BASEDEVs) but that might get changed if we want to.

It's also a draft with big enough holes to drive a truck through but it might inspire ppl.

to take a different look at it and expand on what's here.

Another thing I would like to change from current installs is the vast amount of unused

drivers/protocols and such.

I have only 1 NIC in this machine, it has found and installed the corresponding driver

during install, so I don't have a need for all the other .NIFs and .OS2s in there !

Let's keep it very simple and straightforward : if I add another NIC I'll only want to

install it's drivers (and the latest version) anyway.

Same goes for SCSI, video (SDD should be the only one anyway :-) ), protocols and

whatever there is left that I'm not aware about.

And another thing : NO MORE HARDCODED PATHS !

If current os/2 is smart enough to find it's BASEDEVs in os2\boot it can also find them

using a command-line option.

Changing the BASEDEV loading from BASEDEV=IBMKBD.SYS to BASEDEV=\OS2\BOOT\IBMKBD.SYS

shouldn't impose a massive problem and would make the change to something like below

much easier.

Always on bootdrive :

\ifs (hidden for user)

\hpfs

\cdfs

\udf

\ntfs

\fat32

\ext2

\nfs

\ntwksta

\dev (hidden for user)

\ide

\scsi

\storage

\fixed

\optical

\floppy

\tape

\NIC

\Video

\audio

\usb

\serial

\firewire

\APM

\Printer

\os (r/o for user)

\os2

\bin

\dll

\book

\dos

\unix

\odin

\java

\emx

\shell (r/o for user)

\CLI

\os2

\dos

\bash

\GUI

\wps

\xfree

\network

\protocols

\netbios

\tcpip

\bin

\dll

\dev

\locale (r/o for user)

\I18N

\L10N

\Language

could be on other drive but machine related :

\logs (r/o for user)

\temp (r/o for user)

could be on other drive but shared

\apps (r/o for user)

\app1\

\bin

\dll

\app2

\bin

\dll

\users

\admin (r/w admin)

\desktop

\app1

\app2

\user (r/w user)

\desktop

\app1

\app2

It should be great if specific settings (like dos settings in config.sys) could be

taken out and put in \os\dos\boot\config.sys

The setup is so that it's fairly easy to find an IFS with _all_ it's files or a

device with _all_ it's files.

To add or remove a device or IFS or app or protocol it should only be a

self-contained tree to worry about; no files scattered all over the place.

\os should be seen as an operating environment !

\shell is a human-machine interface; it's a point of discussion whether bash (a *nix shell)

should be under \os\unix as it's not dependent on *nix per se.

It's like being able to get an os2-command prompt under xfree : os2 is too flexible !! ;-)

Richard Gelderblom
2003-09-02 16:28:17

Right !

The formatting got lost :-(

The main dirs are :

\ifs

\dev

\os

\shell

\network

\locale

\logs

\temp

\apps

\users

in \dev\storage are the following four subdirs.

in\os\os2 are the following three subdirs

in \shell\cli are the following three subdirst

in \shell\gui the following 2

you'll get the idea...

BTW as long as there's no real way to create symbolic links we might get by with creating wrappers around executables.

rg,rg

Charles R. Hunter
2003-09-08 07:39:05

Excellent work. This

should have been done ages ago.

Personally I think there are a couple of areas you should be more strict on though:

a) eCS eDFS certified programs should

not be allowed to install in \ecs directories

PERIOD. An exception should be made for

utlities that patch DLLs, but I think some

one shoudl thing *LONG AND HARD* before doing this. 99% of the time there's a better way.

b) programmers should NOT put their own entry in DLLPATH. (or path for that matter)

Make your program smarter than that. It's not tough. Any commandline programs

should be put in Programs\bin or something approriate.

c) I should also comment that you've got the right idea about \ecs being the only thing required for boot. I think that's great.

I suggest you keep the contents of that dir

as small as possible though. It used to dive

me crazy that IBM always assumed a bunch of its dirs were on the 1st boot device, haning off the root directory.

and Finally, I too have to vote for \log going in \var rather than \etc.

\etc is supposed to be user editable

config files, but programs are never supposed to write to anythign on /etc

( unless they are proporting to be on the user's behalf, ala GUI config clients )

My $0.02.

Charles

Wendy Krieger
2003-09-09 09:31:50

I am trying to make the boot partition as small as possible, not make it home to come what may.

Ideally, we should be heading for the direction where we could run the OS and major apps from 'read-only' directories or partitions, and consolidate user applications and data separately.

The advantage of having a tiny bootable system is that the same thing can be used to load, eg the base system and/or a maintanence system, the latter could be home to install/update/fdisk type stuff that is not required for day-to-day running.

That is, the boot sector should load enough to figure out where the user home and the operating system home is, and then continue from there. Some action from the user could activate the minimal maintanence setup, which would allow the user to do things like run an system update or run fdisk. One could do this through a program manager style interface, including a command prompt.

This same thingie could form the basis of a bootable OS/2 off the cdrom, so that one could set up a boot block separately to the program. Hey, the thing could live in the boot-manager, even....

Going for a smaller boot partition allows more operating systems, and the operating system to live anywhere.

wendy

Nicky Morrow
2003-09-12 01:20:49

To Charles:

Thank you for the comments. I understand and will try to include as many of your suggestions as possible in the next release of eFDS.

Teijo Kaakinen
2003-09-29 08:16:41

I'm no expert, but after rereading both FHS 2.2 and EFDS, I would suggest including at least the concepts of /usr and /usr/local to increase modularity and facilitate disaster recovery.

According to fhs 2.2 both /usr and /usr/local contain items used by a non-sysadm, and neither is necessary just to boot the system without a GUI and do basic maintenance work. The basic VIO root system should be bootable and independently functional for maintenance (and sufficient to mount the complete system from eg. a CD-ROM).

/usr and /usr/local differ in that while /usr is designed to contain (partially optional) components and programs which are packaged as part of the distribution, /usr/local contains components which are modified or installed locally. Consequently, while there is flexibility regarding the final contetnts of /usr, it can be recreated without resorting to sources other than the original installation package, leaving /usr/local as the main branch to back up.

This arrangement also has the benefit of making it easy to bypass default components without overwriting them by placing replacement components in /usr/local, and positioning the /usr/local/<directory> entries before other entries in the various config.sys path statements.

Where the /opt (apps) directory is the right location for larger program packages (often with proprietary subdirectories), smaller binaries don't usually need a directory of their own.

Again, those included in the distribution belong in the /usr hierarchy, and additional binaries within the /usr/local hierarchy.

An example would be:

(oot+dll+in+sbin+dev) A bootable basic VIO system.

bootdrive:ecs Other operating system related directories, including WPS. Analogous to /usr.

bootdrive:etc Unsharable configuration files not modified without user/administrator intervention.

somedrive:local Analogous to /usr/local.

somedrive:home User home directories - sharable variable files. (Data produced by users.)

somedrive:programs - Application directories - sharable static files. Analogous to /opt.

somedrive:var Variable data files - unsharable variable files.

somedrive: mp Temporary files

FHS 2.2 initially looks complicated, but despite the compromises necessitated by legacy code it is well thought out. Utilizing it to a greater extent and using the same nomenclature would have benefits when porting applications. Since WPS objects can be named arbitrarily, the "Applications" folder, for example, doesn't care whether the binaries reside in the opt, programs or f00- directory.

Personally, working in an international environment I would also welcome some <man>-like rule for placing of multilingual inf and hlp files, with a compulsory index eg. in the Assistance Center folder. (It's cumbersome to have to rename multilingual .hlp and .inf files to prevent overwriting, and then later try to find them manually.)

I hope this is of some use.

Teijo

Andreas Schnellbacher
2003-10-03 23:13:34

Some questions and suggestions:

1) estyler.ini looks more like holding user settings. It should better

be placed in \home\<user>\etc\estyler.ini.

2) I would have preferred \apps against \programs, but I can live with

it.

3) \programs\book and \programs\doc is missing, if \programs\bin should

become standard. \programs\help may be omitted, but it makes sence

in cases, where a .hlp file, but no .inf file exists: It's much

faster for .inf viewers and other help tools to search in

%bookshelf%;%help% then in %bookshelf%;%path%.

4) Do we really need an \etc dir? The user ini os2.ini is useless

without the handles from system ini os2sys.ini.

What can be put into \etc? Maybe the os2sys.ini should be put into

the user's etc dir as well: \home\<user>\etc\user.ini and

\home\<user>\etc\system.ini, because I (as a user) like to clean-up

my own inis and don't want to use polluted inis by anyone else.

5) I would agree with Thorolf, that log files should be placed in

\var\log.

6) I would like to see the order, main pathes occur in PATH, LIBPATH,

DPATH, HELP and BOOKSHELF, become standardized as well. Should e.g.

\ecs\bin come before \programs\bin or should all user extensions

come first to load the user's files first?

7) Should we get sometimes rid of DPATH, that's required only in some

rare cases?

8) I would like 1 or 2 subdirectory levels of \programs standardized as

well. That would help every user to find applications. We should

not e.g. overtake the Hobbes standard, but discuss this quite well

before realize it.

The subdirs, defined in the standard, should only be a suggestion.

Any user should be allowed to place his applications anywhere he has

write access to (if he knows what he does). The subdirs may differ

extremely on different systems, depending on the user's interests,

supposing the user has admin rights.

9) I would like to see the OS/2 network install dirs removed from root

dir as soon as possible.

10) Where should java, xfree86, emx be installed to? xfree86 must be

placed to a root dir. The emx tree must not be overwritten by emx

runtime files. Therefore the emxrt install should be made

compatible to the full emx install.

11) Should applications write their install pathes to the user.ini or

which other ways are suggested? I think, we should keep this.

Frank Ambacher
2004-11-25 22:38:51

2 all

Someone wrote:

> We don't have a soft-link option (do we?) and

> we don't need compatibility so let's make the

> system USER friendly. As in a common

> computer user, not a computer science guy.

I'm not shure, but I think tvfs can do this. On os level JFS should be able. See Linux JFS.

I would prefer new directory structure on JFS, the old structure can stay on hpfs.

tk
2005-02-15 17:13:52

If anyone still reads this thread this is bound to stir things up, but taking into consideration the fact that gnuish software ports will increase, it might make sense to adopt the FHS in its entirety as a part of the EFDS.

The required root directories would then be:

ecs - static system files (containis all system files in appropriate subdirectories)

programs - bin dll help book doc and other systemish subdirectories for user installed additional files/programs. Analogous to the fhs usr/local directory.

opt - program packages that require their own directory or directory structure

home - user home directories - shareable variable files

etc - unshareable static system settings etc. files

var - unshareable variable settings & other system generated files

tmp - temporary files

...and the rest of the FHS directories:

bin

boot

dev

lib

media

mnt

sbin

srv

If the end user doesn't use unixish programs the redundant directories don't matter, but if he does they make porting software easier.

BTW, I also cast my vote for reserving the etc for static files only. Ideally the boot disk should be completely static.

Comment this article.


Your Name:

Your E-Mail:

CODE:
......

  

Your Comment:


eComStation is recommended for home users: a) no viruses, b) native software + ported programs + start other OSes inside VM, c) A thousand of REXX-scripts aimed to automate small tasks, d) play favorite DOS-games.

Articles

Operating System
Software
Hardware
For developer
Misc
From editor





Last active poll: What is the height of RPM barrier?

[Google]

IBM OS/2 Warp

 
For dummies

Database of OS/2 compatible hardware

 
Reviews


     
  Why eComStation?
Features
Advantages
Usage
Clips and screenshots
   eComStation for
for businessmen
for students and engineers
for reselles of computers
community of users
   Developer
Distribute the program
Description of API, libraries
Start new project
Competition
   Applications
On-line catalogue
Select from eCo Market
   Support service
Contact the web-master
Buy eComStation
Frequently asked questions
for Beginners
 
 
© 2001 - 2021 eCo Software, All rights reserved
Сибирский Медведь технологическая компания
eComStation Serenity Systems International • OS/2 Warp IBM Corporation • ArcaOS Arca Noae