Os file - Revision history

JcHartmut: /* Comparison with Java-file-handling -locking and conclusion

2011-03-06T19:42:12Z

/* Comparison with Java-file-handling -locking and conclusion

← Older revision		Revision as of 19:42, 6 March 2011
Line 45:		Line 45:

	==Comparison with Java-file-handling==		==Comparison with Java-file-handling==
-		+	===Streamed file-io===
	Java knows the <tt>java.io.InputStream</tt> and <tt>java.io.OutputStream</tt>. This both abstract classes are the basics for stream in/out, which are comparable with the lo-level file-io of C respectively the standard file-io using the <tt>FILE*</tt> descriptor, but without <tt>fprintf</tt>-capability. The last one is provided with the <tt>java.io.PrintStream</tt>, derived from java.io.OutputStream. The class java.lang.System contains three references named <tt>out</tt>, <tt>err</tt> and <tt>in</tt> of type of PrintStream respectively InputStream which represents the pipe-concept of command line invocations in the adequate way as C's <tt> stdin</tt>, <tt>stdout</tt> and <tt>stderr</tt>.		Java knows the <tt>java.io.InputStream</tt> and <tt>java.io.OutputStream</tt>. This both abstract classes are the basics for stream in/out, which are comparable with the lo-level file-io of C respectively the standard file-io using the <tt>FILE*</tt> descriptor, but without <tt>fprintf</tt>-capability. The last one is provided with the <tt>java.io.PrintStream</tt>, derived from java.io.OutputStream. The class java.lang.System contains three references named <tt>out</tt>, <tt>err</tt> and <tt>in</tt> of type of PrintStream respectively InputStream which represents the pipe-concept of command line invocations in the adequate way as C's <tt> stdin</tt>, <tt>stdout</tt> and <tt>stderr</tt>.
		+
		+	===Properties of files===

	The handling with file entries in a directory is supported with the class <tt>java.io.File</tt> with its methods <tt>exists()</tt>, <tt>lastModified()</tt> etc. This class is comparable with the <tt>struct OS_FileDescription</tt> and its associated routines defined in the <tt>os_file.h</tt>.		The handling with file entries in a directory is supported with the class <tt>java.io.File</tt> with its methods <tt>exists()</tt>, <tt>lastModified()</tt> etc. This class is comparable with the <tt>struct OS_FileDescription</tt> and its associated routines defined in the <tt>os_file.h</tt>.
		+
		+	===File locking mechanism===
		+	The locking mechanism are defined in the classes <tt>java.nio.channels.FileLock</tt>. This class was created with the Java-version 1.4 about anno 2002.
		+
		+	===Conclusion===
		+
		+	Java provides proper functionality for all file handling requests in its standard packages. A Java-programmer can have confidence to write really portable sources. The adaption to the underlying operation system is assured from the particular Java-Virtual-Machine.

	==Using os_file.h instead file handling with stdio.h==		==Using os_file.h instead file handling with stdio.h==

JcHartmut: Situation of standardizing in C: file locking mechanism

2011-03-06T19:29:11Z

Situation of standardizing in C: file locking mechanism

← Older revision		Revision as of 19:29, 6 March 2011
Line 13:		Line 13:
	==Situation of standardizing in C==		==Situation of standardizing in C==

-	The old C knows two standard to access files:	+	===streamed file-io===
		+
		+	The old C knows two standard to access the content of files:

	* Lo-level file-io using open, read, write with a int handle. This was the originally intension in C. This concept founds the stream-handling of UNIX using pipes, standard- and error.output on console etc.		* Lo-level file-io using open, read, write with a int handle. This was the originally intension in C. This concept founds the stream-handling of UNIX using pipes, standard- and error.output on console etc.
Line 21:		Line 23:
	The interface between the linux-core and the library-layer is adequate to the lo-level-file-system.		The interface between the linux-core and the library-layer is adequate to the lo-level-file-system.

-	~~But in C-programming only~~ the buffered file-io is usual now. The C99-standard doesn't know the routines of the lo-level-file-io. The buffered file-io regards the <tt>stdout</tt>, <tt>stdin</tt> and <tt>stderr</tt> for piping command line applications too. But they are not the int-values 0..2. Rather than they are special FILE-objects supported by the std-library.	+	Only the buffered file-io is usual in C-programming now. The C99-standard doesn't know the routines of the lo-level-file-io. The buffered file-io regards the <tt>stdout</tt>, <tt>stdin</tt> and <tt>stderr</tt> for piping command line applications too. But they are not the int-values 0..2. Rather than they are special FILE-objects supported by the std-library.

	Any C-compiler at any embedded system may offer this file-io-standard-routines and data, but sometimes not in that way how the hardware implements it really. To access the file system which is supported by special packages the routines of the special package should be used instead. The methods are provided in adequate interfaces with adequate names of the routines, but not identical. Often the file-system-component is not integrated in the standard library of the compiler.		Any C-compiler at any embedded system may offer this file-io-standard-routines and data, but sometimes not in that way how the hardware implements it really. To access the file system which is supported by special packages the routines of the special package should be used instead. The methods are provided in adequate interfaces with adequate names of the routines, but not identical. Often the file-system-component is not integrated in the standard library of the compiler.

		+	===Properties of files===
	The query of a last-modified timestamp etc. is defined in C in the POSIX-standard with the method <tt>fstat()</tt> defined in the <tt><sys/stat.h></tt>-header. This standard is regarded in some C- and C++ compiler-libraries but it isn't standardized in the C99-standard and it isn't present in a standardized form for any platform. Therefore the POSIX-standard for that isn't able to use outside of UNIX/Linux/PC programming. There is not a really standard.		The query of a last-modified timestamp etc. is defined in C in the POSIX-standard with the method <tt>fstat()</tt> defined in the <tt><sys/stat.h></tt>-header. This standard is regarded in some C- and C++ compiler-libraries but it isn't standardized in the C99-standard and it isn't present in a standardized form for any platform. Therefore the POSIX-standard for that isn't able to use outside of UNIX/Linux/PC programming. There is not a really standard.

	Therefore the os_file OSAL provides a able-to-use interface. The implementation can use the POSIX-standard if exists or adequate mechanism, which exists in most of file-system-components.		Therefore the os_file OSAL provides a able-to-use interface. The implementation can use the POSIX-standard if exists or adequate mechanism, which exists in most of file-system-components.

		+	===File locking mechanism===
		+	The file locking mechanism are not defined in C99. It means, it isn't defined how to program file locking for portable software. The POSIX-standard defines some mechanism, but they are not available in any cases.
		+
		+	The necessities of file locking are:
		+	* Free read access to files, which are opened to write?
		+	* Open for write exclusively or concurrently?
		+	* If open for write concurrently, a file lock should be possible.
		+	* If open for write concurrently, a record lock should be possible. It locks an existing range in the file.
		+	* The locks should be removed anytime automatically if the file is closed. In this kind hangs of locks should be prevented.

		+	This requests should be defined for portable programming.

	==Comparison with Java-file-handling==		==Comparison with Java-file-handling==

Richard: /* Situation for embedded platforms */

2011-03-06T11:16:33Z

Situation for embedded platforms

← Older revision		Revision as of 11:16, 6 March 2011
Line 5:		Line 5:

	==Situation for embedded platforms==		==Situation for embedded platforms==
-	A file system ~~how it is~~ known from the PC-based software in C is not present in some embedded devices.	+	A file system known from the PC-based software in C is not present in some embedded devices.

	But a handling of special files may be possible. There may be present only a few files with given names, or some files in only one directory level which are stored in the RAM, a flash file system, a remote file system etc.		But a handling of special files may be possible. There may be present only a few files with given names, or some files in only one directory level which are stored in the RAM, a flash file system, a remote file system etc.

-	User software should handle with files, independently how it is deployed in the given hardware platform. If there are only special files, the user software should regard this situation using the given special file-paths while open it. But the user software should not depend on the hardware implementation of the file system. All algorithm should be able to test on PC-platform.	+	User software should handle with files, independently how it is deployed in the given hardware platform. If there are only special files, the user software should regard this situation using the given special file-paths while open it. But the user software should not depend on the hardware implementation of the file system. All algorithm should be able to test on PC-platform.

	==Situation of standardizing in C==		==Situation of standardizing in C==

Admin at 11:00, 6 March 2011

2011-03-06T11:00:31Z

← Older revision		Revision as of 11:00, 6 March 2011
Line 1:		Line 1:
-	==~~Situation~~ in embedded ~~software~~==	+	==Contains==
		+	* Handling with opened streams, adequate fopen, fread, fwrite, flock, ftell, fskip
		+	* Handling with file entries in a directory: exists, write-ability, date last modified, length, absolute path
		+	* supports pipes of command in/output: stdin, stdout, stderr
		+
		+	==Situation for embedded platforms==
	A file system how it is known from the PC-based software in C is not present in some embedded devices.		A file system how it is known from the PC-based software in C is not present in some embedded devices.

Line 19:		Line 24:

	Any C-compiler at any embedded system may offer this file-io-standard-routines and data, but sometimes not in that way how the hardware implements it really. To access the file system which is supported by special packages the routines of the special package should be used instead. The methods are provided in adequate interfaces with adequate names of the routines, but not identical. Often the file-system-component is not integrated in the standard library of the compiler.		Any C-compiler at any embedded system may offer this file-io-standard-routines and data, but sometimes not in that way how the hardware implements it really. To access the file system which is supported by special packages the routines of the special package should be used instead. The methods are provided in adequate interfaces with adequate names of the routines, but not identical. Often the file-system-component is not integrated in the standard library of the compiler.
		+
		+	The query of a last-modified timestamp etc. is defined in C in the POSIX-standard with the method <tt>fstat()</tt> defined in the <tt><sys/stat.h></tt>-header. This standard is regarded in some C- and C++ compiler-libraries but it isn't standardized in the C99-standard and it isn't present in a standardized form for any platform. Therefore the POSIX-standard for that isn't able to use outside of UNIX/Linux/PC programming. There is not a really standard.
		+
		+	Therefore the os_file OSAL provides a able-to-use interface. The implementation can use the POSIX-standard if exists or adequate mechanism, which exists in most of file-system-components.
		+
		+
		+
		+	==Comparison with Java-file-handling==
		+
		+	Java knows the <tt>java.io.InputStream</tt> and <tt>java.io.OutputStream</tt>. This both abstract classes are the basics for stream in/out, which are comparable with the lo-level file-io of C respectively the standard file-io using the <tt>FILE*</tt> descriptor, but without <tt>fprintf</tt>-capability. The last one is provided with the <tt>java.io.PrintStream</tt>, derived from java.io.OutputStream. The class java.lang.System contains three references named <tt>out</tt>, <tt>err</tt> and <tt>in</tt> of type of PrintStream respectively InputStream which represents the pipe-concept of command line invocations in the adequate way as C's <tt> stdin</tt>, <tt>stdout</tt> and <tt>stderr</tt>.
		+
		+	The handling with file entries in a directory is supported with the class <tt>java.io.File</tt> with its methods <tt>exists()</tt>, <tt>lastModified()</tt> etc. This class is comparable with the <tt>struct OS_FileDescription</tt> and its associated routines defined in the <tt>os_file.h</tt>.

	==Using os_file.h instead file handling with stdio.h==		==Using os_file.h instead file handling with stdio.h==
Line 25:		Line 42:

	Sometimes the handling of files is wrapped with functionality of a higher level than the C-standard-file-io. The user uses this wrapper instead the more lo-level C-functions. Inside the wrapper the os_file-routines are called. In that kind the user hasn't any cohesion to the os_file or standard-file handling immediately. The usage of wrappers provides a higher-level interface for the user programming.		Sometimes the handling of files is wrapped with functionality of a higher level than the C-standard-file-io. The user uses this wrapper instead the more lo-level C-functions. Inside the wrapper the os_file-routines are called. In that kind the user hasn't any cohesion to the os_file or standard-file handling immediately. The usage of wrappers provides a higher-level interface for the user programming.
		+
		+	==Description of os_file - Interface==
		+
		+	===Query of properties of files===
		+
		+	The struct <tt>OS_FileDescription</tt> contains the properties for
		+
		+	* fileLength
		+	* flags for query
		+	** exists
		+	** canRead
		+	** canWrite
		+	** hidden
		+	** directory entry or file
		+	* timestamp last modified
		+	* absolute (internal) path of the file
		+	* position of name and relativ path in file to support query it.
		+
		+	The method <tt>os_initFileDescription(this, filepath)</tt> intializes the struct without calling the operation system. The method <tt>os_getFileDescription(this)</tt> accesses the operation system and reads the data from directory entries. The implementation uses <tt>fstat(...)</tt> if a POSIX-compatible access is available.
		+
		+	===stream in/out===
		+	TODO
		+	===file locking===
		+	TODO

Admin: Protected "Os file" ([edit=autoconfirmed] (indefinite) [move=autoconfirmed] (indefinite))

2011-03-06T10:14:29Z

Protected "Os file" ([edit=autoconfirmed] (indefinite) [move=autoconfirmed] (indefinite))

← Older revision

Revision as of 10:14, 6 March 2011

Admin: first

2011-03-06T08:02:08Z

first

New page

==Situation in embedded software==
A file system how it is known from the PC-based software in C is not present in some embedded devices.

But a handling of special files may be possible. There may be present only a few files with given names, or some files in only one directory level which are stored in the RAM, a flash file system, a remote file system etc.

User software should handle with files, independently how it is deployed in the given hardware platform. If there are only special files, the user software should regard this situation using the given special file-paths while open it. But the user software should not depend on the hardware implementation of the file system. All algorithm should be able to test on PC-platform.

==Situation of standardizing in C==

The old C knows two standard to access files:

* Lo-level file-io using open, read, write with a int handle. This was the originally intension in C. This concept founds the stream-handling of UNIX using pipes, standard- and error.output on console etc.

* Buffered file-io using fopen, fread, fwrite, fflush with a structured file handle named <tt>FILE*</tt> defined in < stdio.h>. This was a second stage of file handling in C.

The interface between the linux-core and the library-layer is adequate to the lo-level-file-system.

But in C-programming only the buffered file-io is usual now. The C99-standard doesn't know the routines of the lo-level-file-io. The buffered file-io regards the <tt>stdout</tt>, <tt>stdin</tt> and <tt>stderr</tt> for piping command line applications too. But they are not the int-values 0..2. Rather than they are special FILE-objects supported by the std-library.

Any C-compiler at any embedded system may offer this file-io-standard-routines and data, but sometimes not in that way how the hardware implements it really. To access the file system which is supported by special packages the routines of the special package should be used instead. The methods are provided in adequate interfaces with adequate names of the routines, but not identical. Often the file-system-component is not integrated in the standard library of the compiler.

==Using os_file.h instead file handling with stdio.h==

How it is described in the chapter above, the standard-file-handling doesn't resolve the real expected functionality. Thats why the user programming should not use the standard-file-handling but the os_file-handling. The OSAL-layer adapts the real file handling of the given environment. It can do it because it is a module associated to the users system component, not only associated to the compiler provider.

Sometimes the handling of files is wrapped with functionality of a higher level than the C-standard-file-io. The user uses this wrapper instead the more lo-level C-functions. Inside the wrapper the os_file-routines are called. In that kind the user hasn't any cohesion to the os_file or standard-file handling immediately. The usage of wrappers provides a higher-level interface for the user programming.