fix for ctime and mtime issue #533 and prevents side effect if #532 is implemented - #536
Open
mailinglists35 wants to merge 4 commits into
Open
fix for ctime and mtime issue #533 and prevents side effect if #532 is implemented#536mailinglists35 wants to merge 4 commits into
mailinglists35 wants to merge 4 commits into
Conversation
…mathai#532 is implemented note I have no idea what I am doing (Google Gemini/Colab), it works for me, but this needs a *real world human programmer* review
- Treat composite full_path segments as custom masks - Expand %<name> placeholders from Directory inside location/custom masks - Add unit tests for month-in-location and custom month+location
…cation masks - Replace naive .replace() loops with re.sub callbacks to avoid partial overlaps - Ensure %month expands to full value (02) without leaving 'onth' tail
…e-placeholders Fix: Expand Directory placeholders inside custom/location masks (handle composite masks like %month, %country, %city) issue jmathai#534
Author
|
sorry it seems that while I fixed another issue in my fork, it somehow reflected in this PR. they should normally belong in separate PR. the other fixes are for #534 and another bug discovered when %month together with something else becomes [0-9][0-9]onth |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
note I have no idea what I am doing (Google Gemini/Colab), it works for me, but this needs a real world human programmer review
Google's explanation:
Title: Fix: Prevent source file
ctimealteration during import by deferring EXIF writes to destinationDescription
Motivation / Root Cause Analysis
During a standard
importoperation, Elodie was inadvertently violating the read-only assumption of the source payload, leading to an irreversible alteration of the source file'sctime(inode change time) on POSIX systems.This occurred because
media.set_original_name()directly invokedExifToolto write missing tags into the source file before the copy operation. To mask this mutation,process_file()explicitly calledos.utimeon the source to restore its originalmtimeandatime. However, under POSIX semantics,utimeis a metadata operation that inherently forces the OS to update the file's inodectimeto the current system time. Restoring the originalctimeis impossible via standard unprivileged syscalls, leaving the source file permanently altered at the filesystem level.Modifications
1.
elodie/media/media.py(Architectural Shift):set_original_nameand the internal__set_tagsto accept an optionalfile_pathparameter.sourceproperty from the tag-writing destination. This allows the application to write theoriginal_nametag directly to the destination file after the copy, leaving the source file physically untouched.2.
elodie/filesystem.py(Process Flow Optimization):media.set_original_name()that occurred while the source file was being initially processed.elseblock (standard copy-on-import) to perform a straight copy without prior EXIF tag injections.os.utime(_file, ...)cleanup call targeting the source path. Instead, the logic now invokesmedia.set_original_name(file_path=dest_path), ensuring all metadata modification and timestamp synchronizations are strictly localized to the newly created file in the destination directory.Outcome
The source media file is now treated as strictly immutable by the importer, ensuring full data integrity and nanosecond-accurate
ctime/mtimepreservation for archival workflows. Validated viastatand verified againstmediaandfilesystemtest suites with no regressions.Title: Fix: Restore original
mtime/atimeclobbered by deferred EXIF writes (with nanosecond precision)Description
Motivation / Root Cause Analysis
This patch resolves a critical side-effect introduced by the architectural shift that protects the source file's
ctime.To ensure the source file remains strictly read-only, EXIF tag injections (like
original_name) were deferred to the destination file after the copy/move operation. However, invokingExifToolto write these tags inherently clobbers the destination file's modification time (mtime) and access time (atime), updating them to the exact moment the script is executed. Without explicit restoration, the destination file completely loses its historical modification timestamp.Modifications
elodie/filesystem.py(Absolute Temporal Restoration):stat_info_original—the absolute baseline state captured at the very entry point ofprocess_file(), before any plugins, reads, or deferred EXIF writes can pollute the temporal attributes.os.utimesyscalls immediately following thecopyandmoveoperations to forcibly revert the destination file back to its true historical state, erasing the temporal footprint of theExifToolexecution.ns=): Leveragedstat_info_original.st_atime_nsandstat_info_original.st_mtime_nsvia thens=keyword argument. This bypasses standard floating-point translation and utilizes the underlyingutimensatPOSIX syscall for mathematically perfect time replication, preventing the sub-second truncation often seen in standardshutiloperations.Outcome
The destination payload now inherits the exact, unmodified historical timestamps of the original source file. It successfully survives both the massive
mtimeoverwrite caused by deferred metadata writes and the micro-second truncation inherent to standard filesystem I/O operations.