ktx/pocket_archive

Watch

Fork 0

Incorrect source path in generated LL for implicit container #89

New issue

Closed

opened 2026-10-14 20:14:25 +00:00 by scossu · 2 comments

scossu commented

2026-10-14 20:14:25 +00:00

Owner

If I submit a LL such as:

content_type,id,source_path
still_image,RND001,data/img1.tif

This creates a still_image implicit container with the given RND001 ID, and a still_image_file member with a new random ID, let's say RND002. So far so good; but the source path of the container is set to RND0001, and the one of the image to data/RND0001/img1.tif. This is wrong because a generated LL cannot be submitted using the original file paths:

content_type,id,source_path
still_image,RND001,data/RND001
still_image_file,RND002,data/RND001/img1.tif

The source path of the container should be empty and the one of the image the same as the original LL:

content_type,id,source_path
still_image,RND001,
still_image_file,RND002,data/img1.tif

If I submit a LL such as: ``` content_type,id,source_path still_image,RND001,data/img1.tif ``` This creates a `still_image` implicit container with the given `RND001` ID, and a `still_image_file` member with a new random ID, let's say `RND002`. So far so good; but the source path of the container is set to `RND0001`, and the one of the image to `data/RND0001/img1.tif`. This is wrong because a generated LL cannot be submitted using the original file paths: ``` content_type,id,source_path still_image,RND001,data/RND001 still_image_file,RND002,data/RND001/img1.tif ``` The source path of the container should be empty and the one of the image the same as the original LL: ``` content_type,id,source_path still_image,RND001, still_image_file,RND002,data/img1.tif ```

scossu added this to the v1.2.0 milestone

2026-10-14 20:14:25 +00:00

scossu added the

area/submission

bug

high

labels

2026-10-14 20:14:25 +00:00

scossu added the

area/integrity

label

2026-10-15 02:05:41 +00:00

scossu modified the milestone from v1.2.0 to 1.1.x bugfixes

2026-10-15 02:06:00 +00:00

scossu commented

2026-10-19 21:44:56 +00:00

Author

Owner

This requires some more design and implementation work. The way single-file containers are implemented at the moment is a bit messy and confusing.

Since single-file containers are a shortcut, they can have more restrictions to make them more predictable without sacrificing flexibility.

The rules should be:

If a LL line has source_path pointing to a file in the SIP and content_type that is not a subtype of file, it is considered a shortcut for a single-file container.
The file takes the provided source_path value.
The file gets a newly minted ID.
The container takes the parent (dirname) of the provided source_path value. << NEW RULE
The container takes the provided ID.
If a path identical to the container is already in the LL, an error is raised. << NEW RULE

The last rule requires that all the paths in the LL are scanned in advance. This may have been attempted before, with or without success. Need to review this step.

This requires some more design and implementation work. The way single-file containers are implemented at the moment is a bit messy and confusing. Since single-file containers are a shortcut, they can have more restrictions to make them more predictable without sacrificing flexibility. The rules should be: - If a LL line has `source_path` pointing to a file in the SIP and `content_type` that is not a subtype of `file`, it is considered a shortcut for a single-file container. - The file takes the provided `source_path` value. - The file gets a newly minted ID. - The container takes the *parent* (`dirname`) of the provided `source_path` value. << NEW RULE - The container takes the provided ID. - If a path identical to the container is already in the LL, an error is raised. << NEW RULE The last rule requires that all the paths in the LL are scanned in advance. This may have been attempted before, with or without success. Need to review this step.

scossu commented

2026-10-22 19:38:59 +00:00

Author

Owner

The above proposal is not practical to implement. It would require putting each single file in a different directory, which would create more work than the shortcut saves.

It should be fine to leave the current logic, according to which the container is always created without a source path. It is perfectly legal and reproducible in a round-trip. After all, folders have no special significance for PKAR resources. They are a convenience for the depositor to structure the SIP, which PKAR takes care of reproducing them on restore.

The above proposal is not practical to implement. It would require putting each single file in a different directory, which would create more work than the shortcut saves. It should be fine to leave the current logic, according to which the container is always created without a source path. It is perfectly legal and reproducible in a round-trip. After all, folders have no special significance for PKAR resources. They are a convenience for the depositor to structure the SIP, which PKAR takes care of reproducing them on restore.

scossu referenced this issue from a pull request that will close it,

2026-10-23 02:07:54 +00:00

1.1 branch #91

scossu closed this issue

2026-10-23 02:08:04 +00:00

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

ktx/pocket_archive#89

No description provided.

Rows
Columns