Menu
▾
▴
#228 Maintain Directory Structure in Normalisation
When Xena Normalises a group of objects that includes directories and sub-directories, all the structure is lost during the normalisation process. When the files are exported again, all the objects are together with no directories.
There are cases where the location of a file has a considerable effect on the context and meaning of that file. Consider filing an email under 'Urgent' or 'Reference material'. On a more mechanical level, archived Web pages will lose their internal links if the underlying directories are removed.
I think Xena should have the functionality to preserve directory structure, either by default or as a selectable option.
Logged In: YES
user_id=1303226
Originator: NO
This functionality is already available, but is not exposed in the Xena Lite UI. It *is* used in DPR - if you normalise a bunch of files that are in sub-folders on the media their folder structure will be saved in the wrapper data, and on export they will be sent to that location.
for exmample, if you have a transfer with a file bar.txt in folder foo on media 1, it will maintain that structure in QF ( eg /dpr_data/carrier1/9999_00001111/qf_data/data0001/foo/bar.txt ) and when normalised the 'path' component stored in the wrapper will be /foo/bar.txt, and so when exported xena will put it in the that folder in the output directory - so assuming you are exporting to /xena_data/export the output file will be /xena_data/export/foo/bar.txt
Ofcourse, I dont know if this has been tested rigourously... :)
Logged In: YES
user_id=1810579
Originator: NO
Tested with a zip file containing sub directories and text files. The initial .xena file is the zip file, retains the structure and all content, however the individual .xena files do not.
An interesting mix of functionality here.
Xena by itself does not record structure - If you preserve a directory in DPR - it maintains the structure - but, Copy for Access only gives a bunch of disconnected items.
If however, you access the repository using Xena viewer and the export function, you can re-create the structure no problems.
This leads us into the realms of items, manifests and access/export.
The Xena interface itself cannot recreate directory structure, as it allows files to be added from anywhere on the file system (including mapped network drives, external drives etc) and there would be no base path relative to these files (or one would end up with a very long and convoluted path).
DPR only has one source for its files (the root of the media) so the base path relative to all normalised files is known, and the original directory structure can be recreated.
If the original directory structure is required for Copy For Access, a bug report/feature request should be created.
I have implemented this. In the xena interface there is now a checkbox called "Retain Directory Structure", and is checked by default. If checked, xena will determine the common base path for all files and directories selected for normalisation, and all normalised files will have their "original data source path" set relative to the common base directory. This means exported files will be created with the full relative path in the export directory.
If not checked, all files will just have the file itself as the "original data source path". This means exported files will have no relative path, and will just be created directly in the export directory.
Maintaining directory structure works fine.
Normalised complex directory then exported it from Xena viewer - all sub folders intact.
However, this also happened when I told it not to retain directory structure - check box not working?
The Xena Base Path was being retained from previous runs. It is now cleared at the beginning of each normalisation run.
fix made in Xena:Testing v4.3.15
Tested on Xena Testing Branch 4.3.14.
Normalised several files with the default: Retain Directory Structure option selected.
Directory structure is maintained for exported files.