Opened 13 years ago
Closed 13 years ago
#3897 closed defect (fixed)
GDALRenameDataset on HFA does not update external spill reference
Reported by: | rprinceley | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | 1.8.0 |
Component: | GDAL_Raster | Version: | svn-trunk |
Severity: | normal | Keywords: | HFA |
Cc: | gaopeng |
Description
When renaming an HFA dataset with external spill file, the new dataset maintains reference to old .ige file that no longer exists.
GDALCopyDatasetFiles behaves similarly - creates new copies of .ige and .rrd but dataset uses original files.
Change History (12)
comment:1 by , 13 years ago
Keywords: | gtiff added |
---|---|
Status: | new → assigned |
comment:2 by , 13 years ago
Keywords: | HFA added; gtiff removed |
---|---|
Milestone: | → 1.8.0 |
comment:3 by , 13 years ago
Note, r21433 making CPLCorrespondingPaths() was also needed for some situations, particularly when a .aux.xml file existed.
comment:4 by , 13 years ago
Please back port to 1.6-esri, this is something reported my several users.
comment:5 by , 13 years ago
Frank, could you please update HFABand::LoadExternalBlockInfo() to use HFAGetIGEFilename().
We also need to handle badly renamed files gracefully, will adding a VSIStat() check and falling back to using basename in HFAGetIGEFilename() be alright?
comment:6 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I have significantly reworked the rename/copy logic to work even when there is an .rrd file with a .rde spill file. Added logic in HFAGetIGEFilename() so it falls back to looking for a file with the same basename as the .img file. As suggested I have updated LoadExternalBlockInfo() to use this improved HFAGetIGEFilename(). All done in trunk (r21476).
I also fixed breakage in CPLMoveFile() (r21474) which made renaming large files expensive due to a fallback to copy/delete.
This work has all been backported into 1.6-esri (r21477).
comment:8 by , 13 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Frank,
There is a crash in HFARenameReferences when you rename a file multiple times (GetStringField() returns NULL).
for( i = 0; i < nNameCount; i++ ) { CPLString osFN; osFN.Printf( "nameList[%d].string", i ); aosNL.push_back( poRRDNL->GetStringField(osFN) ); }
We were able to trigger this by increasing the length first then reducing it (exact strings we used: "malaybalayortho_cr.img" -> "malaybalayortho_cr_1.img" -> "test.img").
comment:9 by , 13 years ago
Problem confirmed. There is a problem with the logic circa line 426 of hfafield.cpp when the data array has existing random garbage in it. I will come up with a fix soon.
comment:10 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
I have applied what I think it is a specific and safe fix for the problem in HFARenameDependencies() (by reinitializing the data segment to all zeros and completely reconstructing it). This is applied in trunk (r21575, r21572), 1.8 (r21576,21573), and 1.6-esri (r21577, r21574).
I believe this fixes the issue at hand.
comment:11 by , 13 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
There is a minor issue in cpl_path.cpp (r21433) that causes CPLCorrespondingPaths() to fail if aux.xml file (or other file with different basename) is present in the file list.
if( !EQUALN(papszFileList[i],osOldBasename,osOldBasename.size()) || papszFileList[i][osOldBasename.size()] != '.' )
papszFileList[i] contains full path not basename.
comment:12 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
I have provided a custom implementation of CopyFiles and Rename for the HFA driver which knows how to update RRDNamesList and the .ige reference in trunk (r21432). r21431 and r21428 were also required to get this working.
I'm leaving this ticket open pending of adding of regression tests for this capability.
Robin, do you need this backported to 1.6-esri? I am concerned it is a bit risky.