Changes between Version 5 and Version 6 of rfc12_filemanagement

Timestamp:

May 8, 2007, 1:40:00 PM (17 years ago)

Author:

warmerdam

Comment:

A few updates.

rfc12_filemanagement

@@ -17 +17 @@
 }}}
 
-The method is intended to return a list of files associated with this open dataset.  The return is a NULL terminated string list which becomes owned by the caller and should be deallocated with CSLDestroy().  The default implementation tests the name of the datasource to see if it is a file, and if so it is returned otherwise an empty list is returned. 
+The method is intended to return a list of files associated with this open dataset.  The return is a NULL terminated string list which becomes owned by the caller and should be deallocated with CSLDestroy().  
+
+The default implementation tests the name of the datasource to see if it is a file, and if so it is returned otherwise an empty list is returned.  If the default overview manager is active, and has overviews, those will also be included in the file list.  The default implementation also checks for world files, but only those with extensions based on the original files extension (ie. .tfw or .tifw for .tif) but does not search for .wld since that is not very specific. 
 
 The GDALPamDataset::!GetFileList() method will add the ability to find .aux and .aux.xml files associated with a dataset to the core default behavior. 
@@ -41 +43 @@
 Optionally a NULL hDriver argument may be passed in, in which case the appropriate driver will be selected by first opening the datasource. 
 
-=== CPLMove() ===
+=== CPLMoveFile() ===
 
-The POSIX rename() function on which VSIRename() is usually based does not normally allow renaming files between file systems or between different kinds of file systems (ie. /vsimem to C:/abc).  In order to implement GDALRenameDataset() such that it works efficiently within a file system, but still works between file systems, a new operation will be added to gdal/port.  This is the CPLMove() function which will first try a VSIRename().  If that fails it will use CPLCopyFile() to copy the whole file and then VSIUnlink() to get rid of the old file. 
+The POSIX rename() function on which VSIRename() is usually based does not normally allow renaming files between file systems or between different kinds of file systems (ie. /vsimem to C:/abc).  In order to implement GDALRenameDataset() such that it works efficiently within a file system, but still works between file systems, a new operation will be added to gdal/port.  This is the CPLMoveFile() function which will first try a VSIRename().  If that fails it will use CPLCopyFile() to copy the whole file and then VSIUnlink() to get rid of the old file. 
 
 {{{
-  int CPLMove( const char *pszNewFilename, const char *pszOldFilename );
+  int CPLMoveFile( const char *pszNewFilename, const char *pszOldFilename );
 }}}
 
@@ -70 +72 @@
  * AIGRID: I will implement a custom rename operation in an attempt to handle this directory oriented format gracefully. 
 
-== Outstanding Issues ==
+== Additional Notes ==
 
- * How do we address subdatset oriented files like netcdf, and hdf?  A default implementation would leave the base dataset, opened via the direct filename, as "managable" while the subdatasets would all have empty file lists and thus be unmanagable. 
+ * Subdatasets will generally return an empty file list from !GetFileList(), and will not be managable via Rename or Delete though a very sophisticated driver could implement these operations. 
  * There is no mechanism anticipated to ensure that files are closed before they are removed.  If an application does not ensure this rename/move operations may fail on win32 since it doesn't allow rename/delete operations on open files.   Things could easily be left in an inconsistent state. 
- * Should there be a way for a dataset to indicate that it is not managable?  Perhaps this is the implicit meaning of !GetFileList() returning an empty list? 
+ * Datasets without associated files in the file system will return an empty file list.  This essentially identifies them as "unmanagable". 
 
 == Implementation Plan ==