How do I find the original pathname of a moved file?
Ernest Crvich (192●1●21●19)
| asked Dec 07 '15, 8:23 p.m.
converted to question Dec 08 '15, 4:58 p.m. by Geoffrey Clemm (30.1k●3●30●35)
The code in https://jazz.net/forum/questions/94927 doesn't seem to work if the original directory the file was renamed from no longer exists.
e.g., start with directories foo and bar. Assume you have this file: foo/fubar.java Drag fubar.java from foo into bar to move it (IChange.REPARENT operation). Then delete the empty foo directory. Check these changes in. Your changeset will contain a delete of foo and a move of fubar.java. Now using the API, with the IChangeSet you get the IChange for the file fubar.java and get beforeState(). With this returned object, I cannot find any way to get the old path, either using the IConfiguration for the component, or IVersionableManager. IConfiguration.fetchCompleteItem() throws an ItemNotFoundException when you pass it the fileItem's getParent() returned object, claiming it doesn't exist in the configuration. If you instead use IVersionableManager.fetchCompleteState() on the getParent() object, it claims that the state does not exist. Is there no way to get the previous (deleted) path when you only have the IChange object of the file to use? |
2 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Dec 08 '15, 5:05 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER edited Dec 09 '15, 1:25 a.m.
The short answer is "no".
The explanation is that a file-move change set in RTC does not remember the "previous" path (it only remembers the "previous" parent directory item-uuid, and the name the moved file had in that parent directory). When you accept a "file move" change set into a workspace, it moves that file from wherever that previous parent directory currently exist in that workspace. The previous pathname of a file in the workspace where the move change set was originally created is not considered interesting, and is not stored in the file-move change set. Comments It's pretty interesting/important information to us. For our builds (on zOS), we store part information (which includes the full path, since as you know files with the same name can exist in multiple directories) in a driver database. When a user moves or renames a part in RTC, that needs to be processed in zOS as a two-part delete-and-create action to work properly (the zOS mechanisms do not offer true renames/moves). i.e., the old pathname is marked as inactive/deleted, and the new pathname is added as a new file. It is not the same thing to either (1) treat the scenario as a delta (since the new pathname never existed before), or (2) treat the scenario as just a create (since the old pathname will still exist in the driver).
Geoffrey Clemm
commented Dec 09 '15, 1:37 a.m.
| edited Dec 09 '15, 1:38 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Whether or not "RTC does have this information" it depends on what you mean by "this information". If you mean "the previous pathname of the file in the workspace at the time it was moved", then no, it does not have that information. If you mean "the information needed to implement your use case", then I believe the answer is "yes". In particular, what the RTC knows (and what the RTC GUI can show you) is the path to the previous parent directory in whatever workspace you are currently looking at, and for your use case, I believe that is the path that matters. In particular, suppose you accept a change set into a workspace where that previous parent directory has been moved somewhere else. In that workspace, the previous pathname in the workspace in which the move change set was created is not relevant ... the pathname of that directory in your current workspace is what matters (since that is where you will find the file to be made inactive/deleted). So what you should be looking for is the API that will get you the previous parent item-id from the move operation, and then looking up the pathname of the previous parent item-id in your current workspace. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.