漏洞
ArcGISIndexingServer.exe is writing files unexpectedly during indexing.
| 漏洞 ID 编号 | BUG-000158274 |
|---|---|
| 已提交 | May 12, 2023 |
| 上次修改时间 | July 7, 2025 |
| 适用范围 | ArcGIS Pro |
| 找到的版本 | 2.9 |
| 操作系统 | Windows OS |
| 操作系统版本 | 11.0 64 bit |
| 状态 | Will Not Be Addressed |
附加信息
This issue is not a bug with the indexer. For some reason, accessing properties of the customer's GRID datasets is updating the timestamp of the dataset's auxiliary file (*.aux.xml) even when no changes are made to the auxiliary file or other files associated with the dataset. This occurs when browsing into a folder containing the customer's datasets in the ArcGIS Pro Catalog windows, when adding the datasets to a map, and when opening the Properties dialog box for the datasets. Indexing first gets a list of all datasets in a folder and then retrieves their properties. For raster datasets, indexing uses the same mechanism to access properties of raster datasets as is used when these datasets are browsed in the Catalog windows. The fact that indexing also updates the time stamps for the auxiliary file is understandable because these same operations produce the same result in the ArcGIS Pro UI. It's true that the first time properties are retrieved for the customer's GRID datasets on a Windows 11 computer, the NODATA value in the dataset's auxiliary file is slightly reformatted in a way that doesn't change the NODATA number. The NODATA value for the customer's data is a real number that originally has a leading zero in the exponent. The leading zero is removed from the exponent. i.e., [number]E+038 on Windows 10 is reformatted to [number]E+38 on Windows 11. We have seen similar number formatting issues take place in other scenarios in other files on Windows 11 due to differences in data processing on this operating system. The change to the NODATA number in this case is not concerning. Importantly, the change to the NODATA value happens one time only. However, even after this change occurs, every operation in ArcGIS Pro that retrieves properties from the customer's GRID datasets will continue to update the auxiliary file's time stamp even though nothing else has changed. The change to the NODATA value is unrelated to the underlying problem of why the timestamp for the auxiliary files is updated. Yes, when timestamps are updated on a file even though nothing has changed, this triggers backup systems to get a copy of the latest file, assuming that the file has changed. However, it is not fair to say that this destroys data integrity. It is also not fair to say this is strictly caused by indexing the data. The problem with having the timestamp of the auxiliary files update when properties are retrieved appears to be specific to the customer's GRID datasets. When the same operations are performed on other GRID datasets and other raster formats, the auxiliary file's timestamp does not change. One consideration might be using a different storage format for the customer's raster datasets. If there is a reason a different format can't be used and the backup systems continue to be bogged down by this problem, more investigation must be performed by the raster team. The underlying problem must be resolved in the raster workspace.重现步骤
漏洞 ID: BUG-000158274
软件:
- ArcGIS Pro
当漏洞状态发生变化时获得通知
发现关于本主题的更多内容
搜索相关信息
查找与此主题相关的培训
探索想法并提供反馈
获取来自 ArcGIS 专家的帮助
下载 Esri 支持应用程序