diff options
author | Chris Sherlock <chris.sherlock79@gmail.com> | 2017-05-07 05:45:03 +1000 |
---|---|---|
committer | Chris Sherlock <chris.sherlock79@gmail.com> | 2017-05-07 05:45:03 +1000 |
commit | 6d49392c4b23f04e70baf2b71bcc6485a966b52a (patch) | |
tree | 7974a8b9423c56982646366b0859dfb2a1a88d50 /include | |
parent | 53666e68ef30415a7c89919442e429269e2606f2 (diff) |
osl: small fixes to file.h initial comment
Change-Id: I51eeed1a9afc392c33e60d5cad784136adf28384
Diffstat (limited to 'include')
-rw-r--r-- | include/osl/file.h | 76 |
1 files changed, 38 insertions, 38 deletions
diff --git a/include/osl/file.h b/include/osl/file.h index 9404ffa53dbf..6ef1c09a8459 100644 --- a/include/osl/file.h +++ b/include/osl/file.h @@ -39,48 +39,48 @@ high performance access to file system issues on any operating system. There are a few main goals: -1.The path specifications always has to be absolute. Any usage of relative path -specifications is forbidden. Exceptions are osl_getSystemPathFromFileURL, -osl_getFileURLFromSystemPath and osl_getAbsoluteFileURL. Most operating systems -provide a "Current Directory" per process. This is the reason why relative path -specifications can cause problems in multithreading environments. - -2.Proprietary notations of file paths are not supported. Every path notation -must the file URL specification. File URLs must be encoded in UTF8 and -after that escaped. Although the URL parameter is a unicode string, the must -contain only ASCII characters - -3.The caller cannot get any information whether a file system is case sensitive, -case preserving or not. The operating system implementation itself should -determine if it can map case-insensitive paths. The case correct notation of -a filename or file path is part of the "File Info". This case correct name -can be used as a unique key if necessary. - -4. Obtaining information about files or volumes is controlled by a -bitmask which specifies which fields are of interest. Due to performance -issues it is not recommended to obtain information which is not needed. -But if the operating system provides more information anyway the -implementation can set more fields on output as were requested. It is in the -responsibility of the caller to decide if he uses this additional information -or not. But he should do so to prevent further unnecessary calls if the information -is already there. - -The input bitmask supports a flag osl_FileStatus_Mask_Validate which -can be used to force retrieving uncached validated information. Setting this flag -when calling osl_getFileStatus in combination with no other flag is -a synonym for a "FileExists". This should only be done when processing a single file -(f.e. before opening) and NEVER during enumeration of directory contents on any step -of information processing. This would change the runtime behaviour from O(n) to -O(n*n/2) on nearly every file system. -On Windows NT reading the contents of an directory with 7000 entries and -getting full information about every file only takes 0.6 seconds. Specifying the -flag osl_FileStatus_Mask_Validate for each entry will increase the -time to 180 seconds (!!!). +1. The path specifications always has to be absolute. Any usage of relative +path specifications is forbidden. Exceptions are osl_getSystemPathFromFileURL, +osl_getFileURLFromSystemPath and osl_getAbsoluteFileURL. Most operating +systems provide a "Current Directory" per process. This is the reason why +relative path specifications can cause problems in multithreading +environments. + +2. Proprietary notations of file paths are not supported. Every path notation +must the file URL specification. File URLs must be encoded in UTF8 and after +that escaped. Although the URL parameter is a unicode string, the must +contain only ASCII characters. + +3. The caller cannot get any information whether a file system is case +sensitive, case preserving or not. The operating system implementation +itself should determine if it can map case-insensitive paths. The case +correct notation of a filename or file path is part of the "File Info". This +case correct name can be used as a unique key if necessary. + +4. Obtaining information about files or volumes is controlled by a bitmask +which specifies which fields are of interest. Due to performance reasons it +is not recommended to obtain information which is not needed. But if the +operating system provides more information anyway the implementation can set +more fields on output as were requested. It is in the responsibility of the +caller to decide if they use this additional information or not. But they +should do so to prevent further unnecessary calls if the information is +already there. + +The input bitmask supports a flag osl_FileStatus_Mask_Validate which can be +used to force retrieving uncached validated information. Setting this flag +when calling osl_getFileStatus in combination with no other flag is a synonym +for a "FileExists". This should only be done when processing a single file +(i.e. before opening) and NEVER during enumeration of directory contents on +any step of information processing. This would change the runtime behaviour +from O(n) to O(n*n/2) on nearly every file system. On Windows NT reading the +contents of an directory with 7000 entries and getting full information about +every file only takes 0.6 seconds. Specifying the flag +osl_FileStatus_Mask_Validate for each entry will increase the time to 180 +seconds (!!!). */ - /* Error codes according to errno */ typedef enum { |