Os file
From Java4c
Contents |
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 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
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.
- Buffered file-io using fopen, fread, fwrite, fflush with a structured file handle named FILE* 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.
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 stdout, stdin and stderr 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.
Properties of files
The query of a last-modified timestamp etc. is defined in C in the POSIX-standard with the method fstat() defined in the <sys/stat.h>-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.
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
Streamed file-io
Java knows the java.io.InputStream and java.io.OutputStream. 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 FILE* descriptor, but without fprintf-capability. The last one is provided with the java.io.PrintStream, derived from java.io.OutputStream. The class java.lang.System contains three references named out, err and in of type of PrintStream respectively InputStream which represents the pipe-concept of command line invocations in the adequate way as C's stdin, stdout and stderr.
Properties of files
The handling with file entries in a directory is supported with the class java.io.File with its methods exists(), lastModified() etc. This class is comparable with the struct OS_FileDescription and its associated routines defined in the os_file.h.
File locking mechanism
The locking mechanism are defined in the classes java.nio.channels.FileLock. 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
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.
Description of os_file - Interface
Query of properties of files
The struct OS_FileDescription 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 os_initFileDescription(this, filepath) intializes the struct without calling the operation system. The method os_getFileDescription(this) accesses the operation system and reads the data from directory entries. The implementation uses fstat(...) if a POSIX-compatible access is available.
stream in/out
TODO
file locking
TODO
