Changes between Version 3 and Version 4 of rfc12_filemanagement


Ignore:
Timestamp:
Apr 30, 2007, 8:14:58 AM (17 years ago)
Author:
warmerdam
Comment:

added lots of content.

Legend:

Unmodified
Added
Removed
Modified

  • rfc12_filemanagement

    v3 v4  
    77== Summary ==
    88
    9 Some applications using GDAL have a requirement to provide file management operations through the GUI.  This includes deleting, renaming, moving and packaging up datasets which often requires operations on several associated files.  This RFC introduces an operation on a GDALDataset to identify all the dataset files, and operations move, and rename them.
     9Some applications using GDAL have a requirement to provide file management operations through the GUI.  This includes deleting, renaming, moving and packaging up datasets which often requires operations on several associated files.  This RFC introduces an operation on a GDALDataset to identify all the dataset files, and operations to move/rename them.
    1010
    1111== !GetFileList() ==
    … …  
    5555== pfnDelete() ==
    5656
    57 The delete operations default implementation will be extended to use the !GetFileList() results. 
     57The delete operations default implementation will be extended to use the !GetFileList() results.
    5858
    5959== Supporting Functions ==
    6060
    6161Some sort of supporting functions should be provided to make it easy to identify worldfiles, .aux files and .prj files associated with a file.
     62
     63== Drivers Updated ==
     64
     65It is anticipated that a majority of the commonly used drivers will be updated with custom !GetFileList() methods that account for world files and other ideosyncratic files.  A particular emphasis will made to handle the various formats in gdal/frmts/raw that consist of a header file and a raw binary file. 
     66
     67Drivers for "one file formats" that are not updated will still use the default logic which should work fairly well, but might neglect auxilary world files.
     68
     69 * VRT: I do not anticipate updating the VRT driver at this time since it gets quite complicated to collect a file list for some kinds of virtual files.  It is also not exactly clear whether related files should be considered "owned" by the virtual dataset or not. 
     70 * AIGRID: I will implement a custom rename operation in an attempt to handle this directory oriented format gracefully.
     71
     72== Outstanding Issues ==
     73
     74 * 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.
     75 * 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.
     76 * 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?
     77
     78== Implementation Plan ==
     79
     80This change will be implemented by Frank Warmerdam in trunk in time for the 1.5.0 release.
     81
     82== SWIG Implications ==
     83
     84The GDALRenameDataset() operation on the driver, and the !GetFileList() operation on the dataset will need to be exposed through SWIG.
     85
     86== Testing ==
     87
     88Rename testing will be added to the regression tests for a few representative formats.  These rename operations will be between one directory and another, and will not test cross file system copying which will have to be tested manually.
     89
     90A small gdalrename.py script will be implemented allowing use and testing of the rename operation from the commandline in a convenient fashion. 
     91