Keka
Keka copied to clipboard
aonez
Experimental feature: On extraction preserve file order as in archive by creatively using macOS metadata (i.e. Seq-Nr in Comment or Date-Added with seconds incrementing)
General Idea
Sometimes the order of files in the archive has a real meaning and value
- Which does not correspond to any of the usual capabilities for sorting like
- By name, By various timestamps (created, modified, last opened, added)
But we could facilitate the richness that macOS/Finder metadata offers to preserve that order, i.e.
- List View sorted by Finder Comment, which is a sequence number, which Keka created
- Not to hard to implement I guess: Not even zero padding is necessary, Finder sorts 1,2,3,11,110 correctly in the Comment column, just tested it
- Icon View with custom ordering and Keka ordering them
- Possibly harder to implement. AFAIR some of this Finder icon sizing/grid-aligning/sorting stuff is pretty hard to achieve programmatically because not really officially documented. But maybe that changed meanwhile.
Concrete use case
- https://Balsamiq.cloud (a wep app for wireframing) offers an "Export all screens of this project" function which creates a ZIP archive.
- The source order of the files in that ZIP archive is exactly as in the screens-side-panel.
- Screen names are moved into the file names.
- If a screen name existed multiple times (which is allowed within a project) then the filename gets a number suffix AFAIR.
- Even the creation and/or modification date of the server are preserved in the archive AFAIR.
- Would be so cool to preserve the screen order
Who would use this?
- I am well aware only few people would use this feature.
- And there's sort of a workaround anyhow: Put numerical prefixes in front of the screen names.
- But a pure metadata solution would be so cool! So avantgarde!
- Maybe you are in the mood for it? Or like the challenge of a proof of concept.
- If implemented, the correct place for controlling this would be:
- Preferences > Extracting > Below "Set folder's modification date to extraction date" (which also belong to the "topical complex of metadata" add an option:
-
[ ] Preserve packing order of files in archive by writing sequence number into Finder comment by which you can then sort.
-
- Preferences > Extracting > Below "Set folder's modification date to extraction date" (which also belong to the "topical complex of metadata" add an option:
If you wanted to DIY it should be relatively easy to write a shell one-liner to list files in your chosen sort order and pipe them to zip, etc.
Of course that would not involved Keka, but it would prove usefulness or worth of the idea.
@gingerbeardman I have basic programming and shell scripting knowhow — but decided long ago to stick to what I'm best which is UX design — and only occasionally do some scripting here and there, mostly copying concepts online and only slightly adapting.
What sucks most to me about shell scripting is:
- Character escaping of nested levels (i.e. using awk inside an AppleScript run with osascript). This is often where I give up.
How I would approach the problem at hand
- Set
$archiveFolderNameto basename without extension of $1 - Write output of
unzip -l --formatting-option-for-filepath-only $1 to $archiveListingwhich is a multi line string (aka list) - Run a loop with an increment over $archiveListing
- Set $currentPath to $archiveListing[i]
- Run something like:
unzip --particular-file-only currentFile --output--directory workingDirectory - Command which adds Finder Comment to
./$archiveFolderName/$currentPath- osascript or xattr or surprisingly also exiftool can work quite well with filesystem metadata
But really doing this takes me certainly 2 days, because I'm simply not skilled in it.
I try to keep to using only shell, so I avoid combining AppleScript with shell.
For this, we think of it in two halves:
- we need to get the list of filenames in our desired order
- we need to zip them
So, we know shell commands:
-
lsto list filenames -
zipto zip
We can look up man ls and man zip to find out their options.
And so we arrive at:
ls -t | zip archive -@
...that's it!
Breakdown:
-
ls -tlist files sorted by last modified time (ls -cto sort by created time) -
|pipe results over stdin to next command -
zip archive -@compress to archive.zip accepting filenames via stdin
Going deeper?
- you could replace
lswithmdfind(command-line Spotlight interface) to find files matching specific Finder tags, or some other Finder metadata. You'd just need to make sure the output of the command was one filename per line which I believe is what happens withlsover stdin.
You are mistaken. This is about extracting! You are talking about compressing.
I want to extract the files from an archive and give them a sequence number which corresponds to their order within the archive.
Read again please.
And regarding Applescript: That was just an example. I really mean the difficulty of escaping special characters/operators from the one command encapsulated into the next higher/deeper one. This is always to tricky for me.
In that case I am not sure I see the problem.
Extracting files from an archive will do so in the order that they were added.
Are you not seeing that when you do it?
The order of compressing equals the order extracting. It's the same problem.
list files by order of last modified time
$ ls -t1
dic2pdb
fugodic.pdb
learndic.pdb
mergedic
pbindic.pdb
pdb2dic
prc2dic
rklist
rklist_hira_sjis.pl
romakana.pl
binbodic.pdb
pbinlineapp.prc
pbinlinehack.prc
addseparator.prc
timestamp.prc
zip files by order of last modified time
$ ls -t1 | zip archive -@
adding: dic2pdb (deflated 56%)
adding: fugodic.pdb (deflated 61%)
adding: learndic.pdb (deflated 79%)
adding: mergedic (deflated 40%)
adding: pbindic.pdb (deflated 55%)
adding: pdb2dic (deflated 50%)
adding: prc2dic (deflated 48%)
adding: rklist (deflated 45%)
adding: rklist_hira_sjis.pl (deflated 79%)
adding: romakana.pl (deflated 69%)
adding: binbodic.pdb (deflated 60%)
adding: pbinlineapp.prc (deflated 46%)
adding: pbinlinehack.prc (deflated 49%)
adding: addseparator.prc (deflated 41%)
adding: timestamp.prc (deflated 55%)
inspect zip to check order
$ unzip -t archive.zip
Archive: archive.zip
testing: dic2pdb OK
testing: fugodic.pdb OK
testing: learndic.pdb OK
testing: mergedic OK
testing: pbindic.pdb OK
testing: pdb2dic OK
testing: prc2dic OK
testing: rklist OK
testing: rklist_hira_sjis.pl OK
testing: romakana.pl OK
testing: binbodic.pdb OK
testing: pbinlineapp.prc OK
testing: pbinlinehack.prc OK
testing: addseparator.prc OK
testing: timestamp.prc OK
No errors detected in compressed data of archive.zip.
extract zip to see same order as they were when compressed
$ unzip archive.zip
Archive: archive.zip
inflating: dic2pdb
inflating: fugodic.pdb
inflating: learndic.pdb
inflating: mergedic
inflating: pbindic.pdb
inflating: pdb2dic
inflating: prc2dic
inflating: rklist
inflating: rklist_hira_sjis.pl
inflating: romakana.pl
inflating: binbodic.pdb
inflating: pbinlineapp.prc
inflating: pbinlinehack.prc
inflating: addseparator.prc
inflating: timestamp.prc
Here I add some Finder comments, sort, and compress (not using Keka).
Comments last (ascending):
❯ unzip -t Archive.zip
Archive: Archive.zip
testing: binbodic.pdb OK
testing: dic2pdb OK
testing: fugodic.pdb OK
testing: mergedic OK
testing: pbindic.pdb OK
testing: pbinlineapp.prc OK
testing: pbinlinehack.prc OK
testing: prc2dic OK
testing: rklist OK
testing: rklist_hira_sjis.pl OK
testing: romakana.pl OK
testing: pdb2dic OK
testing: __MACOSX/._pdb2dic OK
testing: addseparator.prc OK
testing: __MACOSX/._addseparator.prc OK
testing: timestamp.prc OK
testing: __MACOSX/._timestamp.prc OK
testing: learndic.pdb OK
testing: __MACOSX/._learndic.pdb OK
No errors detected in compressed data of Archive.zip.
Comments first (descending):
❯ unzip -t Archive.zip
Archive: Archive.zip
testing: learndic.pdb OK
testing: __MACOSX/._learndic.pdb OK
testing: timestamp.prc OK
testing: __MACOSX/._timestamp.prc OK
testing: addseparator.prc OK
testing: __MACOSX/._addseparator.prc OK
testing: pdb2dic OK
testing: __MACOSX/._pdb2dic OK
testing: binbodic.pdb OK
testing: dic2pdb OK
testing: fugodic.pdb OK
testing: mergedic OK
testing: pbindic.pdb OK
testing: pbinlineapp.prc OK
testing: pbinlinehack.prc OK
testing: prc2dic OK
testing: rklist OK
testing: rklist_hira_sjis.pl OK
testing: romakana.pl OK
No errors detected in compressed data of Archive.zip.
Yes but how can I utilize that order in the file browser. Answer not at all as-is.
- Sorting by filename
- Nope. That is not the screen order.
- Sorting by creation date or modification date
- Not if extracted by macOS built-in unarchiver, it uses something else than the archive order. No idea what.
- Maybe with command line
unzipif moddate/creationdate are simply using the time of decompressing and not respecting the timestamps as embedded in the archive would then correspond to archive order. But again:- The time granularity (in the file system or the one Finder uses for ordering by date/time) may not be fine enough and multiple files have the same date/time and would then again be sorted by a different criteria (i.e. lexicographically)
- And as soon as I edit or touch files, the screen order is lost again.
- Hence the idea to preserve this with a sequence number. Any idea how to do that?
We have seen proof that the order of files is preserved in the archive based on the sorting order and metadata set at the time of compression. Keka deals only with compression and extraction.
- Filename order - works
- Created/modified - works
- There is no Maybe with unzip, the behaviour is documented exactly.
- Time granularity - it doesn't mater, nothing happens when the files are in the zip.
- The order they go in is the order they come out. This behaviour is by design.
- Whatever sort you have in Finder/browser is the order that is set. Keka is not the one to help you sort your files.
Maybe your request is outside the remit of Keka? It is more a Finder or file management request IMHO.
I wish you good luck.
By design file order is the same at extraction as it was at compression.
So the order is already preserved. There is nothing to do.
Can you give us some example screenshots/recordings if you are not seeing this behaviour?
What happens to the order when you extract the Balsamiq zip in your first post?
I had prefixed the title with "Experimental feature" as I was aware this is an exotic feature request serving only few people. I now further updated the title to better reflect what exactly is desired.
I have no doubt that zip can preserve order both during compression and decompression. You have demonstrated that very well, thanks for your efforts!
My request is about making that in some cases valuable information of source order in the archive accessible to the file browser (be it Finder or also ls). Either by utilizing the Finder comment for storing a sequence number there or by utilizing the "Creation date" or "Modification date" (not restoring them from the archive metadata but setting them to the time of decompression) or better put that into "Added date" and preserve "Creation date" or "Modification date" from the archive metadata (if stored). Which if the decompressing tool performs decrompression by source order we'd get for free.
I will offer screenshots in a few minutes.
Notes
- ZIP once decompressed with Archive Utility (of macOS) vs. once with Keka.
- All windows are scrolled to the top (as the viewer of this you cannot be sure due to the lack of scrollbars)
- EVM with Archive Utility - Sorted by Date Modified - Once ascending vs. once descending
- Notice the strange discrepancy: DISCARDED and OUT OF SCOPE are always in that same order regardless whether sorted asc or desc. So the Finder definitely does something wrong regarding sorting my time or the timestamp granularity of APFS is insufficient (I doubt it) or the utility falsely sets them all to the same time (i.e. start of batch, or end of batch) and not when starting to write out or finished writing out.
- And in the "Date Modified ^" display order thye should not be in the middle of the list but at the bottom, not even visible within the viewport. Very strange.
- And overally: None of the three windows displays the order as the screen order in the web app and its archive export.
Again both folders, all sorted by ModDate, each once asc, once desc. Same strange pattern observable:
I think I'm beginning to see what you want...
For a snapshot of the order present in the zip to be baked into metadata so it can be recalled even after the files (and thus current sort order) are changed. Right?
Let me think on this a little.
For a snapshot of the sort order to be baked into metadata so it can be recalled …
FULL STOP. That alone would already by nice. As the screenshots show the result from Archive Utility or Keka in combination with Finder displaying be moddate does not even achieve that.
… even after the files (and thus current sort order) are changed. Right?
Yes if the first criteria worked then that second criteria would also be important. To preserve it stably. You got that right too.
A solution to this is appreciated!
One more important thing to clarify that there is not yet again a misunderstanding:
- The only "baking in" of screen order into the archive is the order of the files in the archive.
- This very likely is no Mac at all, most likely a Linux server.
- On extraction the file order in the archive shall be "baked in" to the metadata of the extracted files. So this is were Keka or our shellscript would kick in.
Or in other words: The compression part is not in our hands, we only have control over the decompression part, and want to utilize the info from the creation part by utilizing macOS metadata capabilities in the filesystem "creatively". I read that you are a former Apple tech evangelist, so you sure know those capabilities extensively 😉
It would be useful would be to have an example ZIP that we can use for ongoing tests and to work through this.
Could you please create one? One from Balsamiq sounds like it would fill our needs.
I will first try some sort of shell script to manage the extraction, using the sort order to create the "baked" metadata (Finder comments with numerical order of files). Then let's discuss.
Balsamiq project "Test" with screen order
- 01
- Emanuel
- Berlitz
- 02
- Amy
- Xerxes
Balsamiq ZIP export with PNGs
Order in ZIP is equivalent to screen order on Balsamiq.cloud
unzip -l ~/Downloads/Test.zip
Archive:
Length Date Time Name
--------- ---------- ----- ----
10829 11-25-2021 15:00 01.png
12594 11-25-2021 15:00 Emanuel.png
13927 11-25-2021 15:00 Berlitz.png
13347 11-25-2021 15:00 02.png
13886 11-25-2021 15:00 Amy.png
13205 11-25-2021 15:00 Xerxes.png
--------- -------
77788 6 files
@gingerbeardman Any progress with the demo data? As you may guess I have the one or other pressing use case which would benefit from a solution 😉
So I realistically categorize it into "given up". No worries!
Maybe someone else? @aonez maybe?
No, not given up. I'd have said so if that was the case.
Please continue to keep reminding me about it!
Christmas period is very busy for me.
I had a small break whilst I waited for something to finish. Almost done :)
OK, now I see the exact problem we are dealing with.
$ unzip -l Test.zip
Archive: Test.zip
Length Date Time Name
--------- ---------- ----- ----
10829 11-25-2021 15:00 01.png
12594 11-25-2021 15:00 Emanuel.png
13927 11-25-2021 15:00 Berlitz.png
13347 11-25-2021 15:00 02.png
13886 11-25-2021 15:00 Amy.png
13205 11-25-2021 15:00 Xerxes.png
--------- -------
77788 6 files
The zip has the files in the correct order, but they all have exactly the same time (only to minute granularity).
This means that the date and modified times are set to those, all files the same, and so the order is lost upon extraction.
I've been using unzip so far.
So, more thought needed to maintain the order (somehow!) during unzip. I have some ideas. Maybe not today.
Life is a rollercoaster.
OK, done! 😎
Source code:
https://gist.github.com/gingerbeardman/5239df9d087df952bf7ed054ed35b10c
Usage:
$ ./extract-and-bake-order.sh Test.zip
What it does
- extact zip into folder of the same basename
- add comments with numbers based on original order in zip
- change modified time of each file so second represents order
- no information is removed, only comments are added
Verify zip ordering:
$ zipinfo -1 Test.zip
01.png
Emanuel.png
Berlitz.png
02.png
Amy.png
Xerxes.png
Output
Final results:
Yes, to me this was clear from the beginning on. I wanna state it explicit now:
On the server
- Screen order is ONLY reliably encoded in archive-order.
- Date Created and Date Modified do not at all refer to screen order. Because you create and modify your screens independent of their order. Many Linux systems anyhow only keep the Date Modified. And most systems also don't preserve it when putting things into ZIPs, but will simply give no timestamp at all or simply use the timestamp of the operation.
- But if such a cloud service provider would go the extra mile and really preserve screen creation and modification timestamps from their database/XML/JSONs into the PNG image file exports, then we wanna preserve those and not abuse them for baking in the screen order.
On the Mac
- Due to that "maximum preservation approach" the idea to encode order in the Finder comments.
- Or if using a date-field to encode order, "Date Added" would be quite suited. We could simply use the time of operation for the last screen, and minus one second for every previous screen.
No worries, it's all done, see above https://github.com/aonez/Keka/issues/932#issuecomment-989762514 👍
My thoughts on Keka regarding this: it would be more useful to have a general option
- "process extracted files with command/script" than to have one specific option
- "preserve ordering by baking it into metadata" what do you think?
That way we could do anything to the extacted files:
- bake sort order
- HFS compress them
- colour code them
- set extended atttributes
- move them to specific folders based on type
- etc
Limited only by our imagination! 🧠
Thanks for suggesting this problem, it was fun to think about and solve! 🙌
@gingerbeardman I tried out your script. Thanks!
- My next comment will be on the status quo of the script and possible improvements (both as a video and comment text).
- In my next next comment I will react to your proposal.
https://user-images.githubusercontent.com/737143/145404063-f25affde-a883-4cfc-8ea4-b6c1568f9bad.mp4
Finder List View (CMD-2) 👍 Fine with order baked into comments
View Options (CMD-J)
ℹ️ Sort by: Comment --> Not available. ✅ But set "Show Columns" > "Comments" on. Then click that column to sort by it.
Finder Icon View (CMD-1): 👎 No solution yet
View Options
ℹ️ Sort by: Comment --> N/A!
Workaround also fails
- Sort by: None
- Menu > Select all (CMD-A)
- Menu > View > Clean Up By: Comment --> N/A!
Finder Icon View: 💡 We could get it better by
- Baking screen order into "Date Added".
- 🙂 Better because "Date Added" is available in "Sort by".
- ❌ But not yet allright cause "Date Added" is not available in "Clean Up By".
Finder Icon View - 💡 How to get it totally right?
-
💡 With "Clean Up By" we could even bake screen order into the visual freestyle icon order which you get if you sort by "None" or "Snap to Grid".
-
😎 How cool would that be! You get the server screen order into your visual icon order and could even continue moving screens around on your Mac to prioritize or organize further.
-
❗️ Manipulating Finder icon order programmatically is certainly harder than with baking it into an available field and then passing it to the visual order with the manual one shot operation "Clean Up By".
Solution approaches
Tags
- Spamming the Tag Namespace with "1" to "100" or "nr1" to "nr100" not so nice.
- But ok, because after "Clean Up By" you could remove them again.
- Even via command line with "tag --remove" (available on HomeBrew).
Modification Date
- Sacrifice it.
- Totally acceptable if the server does not preserve it anyhow.
- As Finder can't reliably sort by nanoseconds we need a full second per screen.
- Hence your control structure gets more complicated.
Ideas
- Decompress just one file, wait 1 sec, decompress next file. Cheapest. Acceptable wait time.
- But what about reverse order?
- No problem for list view which has asc+desc.
- But "Clean up by" just goes in one direction I guess. Maybe unzip can run in reverse order?
- Postprocess.
- Bake order into comments during loop.
- When done with decompression loop by seq-nr from the highest to the lowest.
- Either with simply touch, wait 1 sec, touch wait 1 sec, … --> Acceptable wait time IMHO.
- After loop delete comments of all files.
- Or more sophisticated:
- $lastModDate = modDate of file from highest seq-nr
- Loop by seq-nr from the highest to the lowest,
- Set modDate of $currentFile to ($lastModDate - $i seconds)
- Even simpler maybe if ok with shifting the moddate before the download date
- $seqNrMax = The total amount of screens
- $firstModDate = modDate of file with lowest seq-nr
- Loop by seq-nr
- Set modDate of $currentFile to ($lastModDate - $seqNrMax- $seq-nr seconds)
- Bake order into comments during loop.
My thoughts on Keka regarding this: it would be more useful to have a general option
- "process extracted files with command/script" than to have one specific option
- "preserve ordering by baking it into metadata" what do you think?
Would be very cool.
- In that scenario Keka would still handle "all things regarding decompression"
- But would provide a scripting environment with as much metadata as possible (archive order including)
- And then those scripts can use the list of files and all its attached metadata which get standardized variable-names such as $archiveOrder $dateCreated $dateModified etc in an easy fashion.
- And some scripts are already shipped with Keka, hence simply selectable as a dropdown-menu-choice for users who need such options but who are not skilled enough to write such scripts on their own.
Because of course Keka shall first and foremost be a convenient Mac GUI app for compression and decompression. So the decompression part shall NOT be handled by scripts. Else we'd get inconsistent behavior. And what would be the point of Keka then. So those scripts shall only get an environment in which they can work with the decompressed files and plenty of metadata sources and possible targets, like the ones you mention next:
That way we could do anything to the extacted files:
- bake sort order
- HFS compress them
- colour code them
- set extended atttributes
- move them to specific folders based on type
- etc
Limited only by our imagination! 🧠
Thanks for suggesting this problem, it was fun to think about and solve! 🙌
Cool way your phrase it! Feels like a win win! Designer mind and developer/tinkerer coming together and both enjoying the problem/solution progress. Great! Anytime again! Time allowing ofc.
Use of tags worries me because user may have other tags that are overwritten.
Though I do not like the idea of destroying or modifying the file data away from what it should be, I guess we're out in the weeds at this point anyway ...so to hell with it.
I don't have any more time today, but what could be done:
- get modified
timestampof parent zip (or first file in zip?) - when baking set each file modified time to
timestamp+(order*seconds)
Use of tags worries me because user may have other tags that are overwritten.
- With
tagyou can--addand--removespecific tags, not only overwrite the whole Finder Tag xattr living in com.apple.metadata:_kMDItemUserTags.
- So even archives with files with Finder tags would remain unharmed.
- Only exception: A file indeed has a "nr-23" tag on purpose, then we would remove it as a false positive auxillary tag. But how likely is that? Hence "nr-23" and not "23" which is more likely to carry real meaning. Simply use a very unique prefix like "nr-" or "archive-nr-" or better something close to the end of the alphabet like "x-archive-nr-" to not spam the namespace too much anyhow.
- At the end of the postprocessing we would safely remove all our "nr-*" tags.
- Maybe
tag --removeeven supports wildcarded tags, I will inquire. - But if not also no problem. Because we know the length of the loop. We can simply explicitley
tag --remove nr-1 nr-2 … nr-Last
I do not like the idea of destroying or modifying the file data away from what it should be
- Generally yes, but as laid out above I think it is safe and lossless.
- This would be the "maximum preservation mode"
I don't have any more time today, but what could be done:
- get modified
timestampof parent zip (or first file in zip?)- when baking set each file modified time to
timestamp+(order*seconds)
Yes, I'd love that. Because then I could "Clean up by" and have my visual icon order and could finish my project 😉
The maximum preservation mode can still be our long time goal 🙂
OK, using modified date is done. 🕐
Code link updated https://github.com/aonez/Keka/issues/932#issuecomment-989762514
edit: updated again to change seconds rather than minutes.
Saved myself both your revisions as archive-order-to-comment.sh (from the first revision) and archive-order-to-date-modified.sh from the currently latest revision (technically bakes order to comment AND date-modified). And decompressed with both. Observations:
- Local vs UTC time issue: Outcome differs by 1 hour between the different script-revisions
-
archive-order-to-comment.shcreates 2021-11-25 15:00:xx -
archive-order-date-modified.shcreate 2021-11-25 16:00:xx
-
We need to create the "Date Modified" in reverse order (last screen has oldest timestamp) because in Finder > Icon View > Sort By "Date Modified" only can sort with newest on top. There's no workaround to get oldest on top. Offtopic: This inflexibility also annoys me in other Finder use cases. So our script needs to reverse this.
-
FYI: Interesting ambiguity
date -r [seconds|filename]where a screen "01" (without a file suffix) would be misinterpreted as "01" seconds since epoch start. Screen name 01 is quite realistic. But since macOS X files usually use suffixes. So we can de facto forget about it.
See details
➜ ~ man date
-r seconds
Print the date and time represented
by seconds, where seconds is the
number of seconds since the Epoch
(00:00:00 UTC, January 1, 1970; see
time(3)), and can be specified in
decimal, octal, or hex.
-r filename
Print the date and time of the last
modification of filename.
# Wondering what date prefers in doubt?
# 66 seconds since epoch start or file "66" ?
➜ ~ mkdir test-date
➜ ~ cd test-date
➜ test-date date -r 66
Thu Jan 1 01:01:06 CET 1970
➜ test-date touch 66
➜ test-date ls -l
total 0
-rw-r--r-- 1 sn staff 0 Dec 9 18:08 66
➜ test-date date -r 66
Thu Jan 1 01:01:06 CET 1970
# Ok in doubt it prefers SECONDS.
# Screens with NUMBER ONLY FILENAME are quite realistic.
# But they will have a file suffix nowadays.
# MacOS 9 already long gone.
# Edge case that we do not need to care about.
That last fix (fake moddate in reverse batch order) and I could really do my intended work in the Finder.
I'm good in UX design and QA, but not in DEV.
I could perform this last fix myself for sure. But I sure need 10 times longer than you, a lot more trial'n'error and suffering involved 😉
-
First real world scenario test with file names having spaces or special characters auch as "smaller-than or greater-than and the script already
f***sup massively.f***smean "fails" ofc. 😉 -
As I commented earlier
What sucks most to me about shell scripting is: Character escaping and handling whitespace
- I created a new test-set with varying difficulty: The shorter the filename the easier the complexity:
https://user-images.githubusercontent.com/737143/145459422-8c9f7c9b-aec4-46f3-b2ad-d4b5e7499c38.mp4
Test Set
test-en.zip test-en-spaces.zip test-en-spaces-fr.zip test-en-spaces-fr-gr.zip test-en-spaces-fr-gr-emoji.zip test-en-spaces-fr-gr-emoji-persian.zip
Let me see how it fails (one screenshot).
I'm away from my computer but I still have my brain with me to think about solutions.
All filenames are quoted. Hoping it's something else. 😬
I can remove the AppleScript and do Finder comment another way. This was just the quickest way (first Google result).
Reverse modified time is an easy change.
This is how it fails:
➜ ~ cd ~/full-test-sets
➜ full-test-sets ls -l
total 2728
-rw-r--r--@ 1 sn staff 275K Dec 9 19:51 test-en-spaces-fr-gr-emoji-persian.zip
-rw-r--r--@ 1 sn staff 227K Dec 9 19:51 test-en-spaces-fr-gr-emoji.zip
-rw-r--r--@ 1 sn staff 195K Dec 9 19:52 test-en-spaces-fr-gr.zip
-rw-r--r--@ 1 sn staff 150K Dec 9 19:52 test-en-spaces-fr.zip
-rw-r--r--@ 1 sn staff 150K Dec 9 19:53 test-en-spaces.zip
-rw-r--r--@ 1 sn staff 150K Dec 9 19:54 test-en.zip
➜ full-test-sets archive-order-to-date-modified.sh test-en-spaces-fr-gr-emoji.zip
Archive: test-en-spaces-fr-gr-emoji.zip
extracting: test-en-spaces-fr-gr-emoji/01 this and that.png
error: cannot create test-en-spaces-fr-gr-emoji/Emmanuel Jean-Michel Fr+?d+?ric Macron.png
Illegal byte sequence
extracting: test-en-spaces-fr-gr-emoji/Berlitz.png
error: cannot create test-en-spaces-fr-gr-emoji/02 or emoji 2??????.png
Illegal byte sequence
extracting: test-en-spaces-fr-gr-emoji/Amy.png
error: cannot create test-en-spaces-fr-gr-emoji/+?+???+?+???.png
Illegal byte sequence
extracting: test-en-spaces-fr-gr-emoji/Xerxes.png
Baking order: 01
Baking order: this
Baking order: and
Baking order: that.png
Baking order: Emmanuel
Baking order: Jean-Michel
Baking order: Fr+?d+?ric
touch: test-en-spaces-fr-gr-emoji/Fr+?d+?ric: Illegal byte sequence
Baking order: Macron.png
Baking order: Berlitz.png
Baking order: 02
Baking order: or
Baking order: emoji
Baking order: 2??????.png
touch: test-en-spaces-fr-gr-emoji/2??????.png: Illegal byte sequence
Baking order: Amy.png
Baking order: +?+???+?+???.png
touch: test-en-spaces-fr-gr-emoji/+?+???+?+???.png: Illegal byte sequence
Baking order: Xerxes.png
The visual outcome in Finder:
OK!
updated: https://gist.github.com/gingerbeardman/5239df9d087df952bf7ed054ed35b10c
I am such an idiot
- split filenames: fixed (my misunderstanding for how a bash for loop works)
Pass
- hour difference: your French time zone is different than the timezone on the files in the zip, which is coincidenally my time zone (i think we have to live with this one for now)
Todo
- illegal byte sequences: this one is character encodings (will take some investigation as to how best to fix it; i have to inspect each command to see if it needs to be told to run as UTF-8; no joy with my usual quick fix)
-
First things first: I'm Austrian not French! 😂 — Just chose French accents and the French president as an example of non-ASCII characters. My observation: When the Anglosaxon world thinks of something foreign, the stereotypical imagination is always France/French. 😉 Can provide you with öäü Umlauts too if you want 😉 just joking, our test sets should suffice as is.
-
Hour Difference: Server time vs. local time cannot be the reason! I decompressed the very same zip file. Once with
archive-order-to-comment.shand once witharchive-order-to-date-modified.sh. So the reason has to be in the difference between the two script variants. See this visual diff here:
- Illegal byte sequences: Character encodings definitely. Hope you can fix it.
OK!
updated: https://gist.github.com/gingerbeardman/5239df9d087df952bf7ed054ed35b10c
- Illegal byte sequences: fixed (switched to using 7z for filenames and extraction as it copes with characters encodings very well, previously was using standard zip)
Hour difference
to modify the timestamp i need to retrieve the timestamp from the file (DATESTAMP) and convert it to a format suitable for writing (TOUCHSTAMP) and i reference timezone here %Z, but not in the destination format +"%Y%m%d%H%M.%S" so that will assume your computer local timezone, which is where the hour is added.
For me:
$ date -r Amy.png
Thu Dec 9 22:02:17 GMT 2021
$ date -jf "%a %b %d %T %Z %Y" "$DATESTAMP" +"%Y%m%d%H%M.%S"
202112092202.17
We can adjust timezone...
TZ=America/New_York date -jf "%a %b %d %T %Z %Y" "$DATESTAMP" +"%Y%m%d%H%M.%S"
202112091702.17
...but we need to think about the implications of hard coding this setting.
Yes, brew install p7zip
This is the parent package that contains many commands, like 7z etc
I plan to remove the AppleScript, and replace with a call to osxmetadata
So, in the near future, you'll need to do pip install osxmetadata to install that. Let me know if it is a problem.
I have done the change locally with my script, will upload the much shorter version when you let me know you have installed osxmetadata OK.
Tested
✅ All files have proper Unicode filenames. Even Old Persian! ✅ Allmost all files decompress and get order baked into comment and date-modified ❌ except Persian png: Which has 0 bytes and no proper comment fake-moddate-timestamp ❌ Missing feat: Script needs that reverse fake-mod-date-order so that "Clean Up By" can succeed. ℹ️ Ideally you can run the script with arguments: -c --comment -m --date-modified -M --date-modified-reverse
-m and -M are mutually exclusive. -c or -m can be combined If no arg submitted it assumes -cm
Persian bug
the Persian file is not in test-en-spaces-fr-gr-emoji.zip for me?
new file uploaded, you'll need osxmetadata installed!
https://gist.github.com/gingerbeardman/5239df9d087df952bf7ed054ed35b10c
- reverse datestamp order
- removed osascript and replaced with osxmetadata
I'm willing to install pip.
- First attempt failed. Had outdated Python.
- Used bootstrap pip install script.
- Then realized:
WARNING: The scripts pip, pip2 and pip2.7 are installed in '/Users/•••/Library/Python/2.7/bin' which is not on PATH.
Is it normal to install this in userland? Or should I have run "sudo python get-pip.py" to install this globally?
I forget how I installed pip, sorry! One for tomorrow.
That's it from me for now.
Ok then.
Last observation which can only be explained by voodoo:
➜ full-test-sets ls -l
total 2728
-rw-r--r--@ 1 sn staff 281473 Dec 9 19:51 test-en-spaces-fr-gr-emoji-persian.zip
-rw-r--r--@ 1 sn staff 232767 Dec 9 19:51 test-en-spaces-fr-gr-emoji.zip
-rw-r--r--@ 1 sn staff 199804 Dec 9 19:52 test-en-spaces-fr-gr.zip
-rw-r--r--@ 1 sn staff 153980 Dec 9 19:52 test-en-spaces-fr.zip
-rw-r--r--@ 1 sn staff 154074 Dec 9 19:53 test-en-spaces.zip
-rw-r--r--@ 1 sn staff 154074 Dec 9 19:54 test-en.zip
-rw-r--r--@ 1 sn staff 211361 Dec 9 20:01 test-sets-with-varying-complexity.mp4
➜ full-test-sets archive-order-to-date-modified.sh test-en-spaces.zip
Extracting archive: test-en-spaces.zip
Everything is Ok
Baking order: 01 this and that.png
Baking order: Emmanuel Jean-Michel Frédéric Macron.png
Baking order: Berlitz.png
Baking order: 𐎧𐏁𐎹𐎠𐎼𐏁𐎠.png
Baking order: 02 or emoji 2️⃣.png
Baking order: Amy.png
Baking order: Ξέρξης.png
Baking order: Xerxes.png
➜ full-test-sets archive-order-to-date-modified.sh test-en-spaces-fr-gr.zip
Extracting archive: test-en-spaces-fr-gr.zip
Everything is Ok
Baking order: 01 this and that.png
Baking order: Emmanuel Jean-Michel Frédéric Macron.png
Baking order: Berlitz.png
Baking order: 𐎧𐏁𐎹𐎠𐎼𐏁𐎠.png
Baking order: 02 or emoji 2️⃣.png
Baking order: Amy.png
Baking order: Ξέρξης.png
Baking order: Xerxes.png
➜ full-test-sets
Looking at these ZIPs with my quicklook preview plugin BetterZip shows that the Persian PNG is only in the ZIP labeled Persian. Nevertheless it appears also in the others. You echo is not enough to be sure. Maybe 7z is using some sort of caching? Or your script indeed uses another ZIP than it tells us :-)
Will isolate them in different folder to be sure no confusion takes place.
Try official installation guide of osxmetadata: https://github.com/RhetTbull/osxmetadata
$ brew install pipx
$ pipx install osxmetadata
^ Way more convenient installation.
Already spoilt from the convenience level of brew (no sudo, all so easy cheesy) and how brew itself got installed (1 liner which downloads itself with wget and then runs right away) the installation instructions as https://pip.pypa.io/en/stable/installation/ were less convenient and more error prone.
Got the bug: Your script indeed caches the ZIP filepath somewhere (in an environment variable I guess) and always tried to expand the persian ZIP, even when in a folder without the persian ZIP. See this:
➜ cd /isolated-test-set-persian
➜ isolated-test-set-persian archive-order-to-date-modified.sh test-en-spaces-fr-gr-emoji-persian.zip
Extracting archive: test-en-spaces-fr-gr-emoji-persian.zip
Everything is Ok
Baking order: 01 this and that.png
Baking order: Emmanuel Jean-Michel Frédéric Macron.png
Baking order: Berlitz.png
Baking order: 𐎧𐏁𐎹𐎠𐎼𐏁𐎠.png
Baking order: 02 or emoji 2️⃣.png
Baking order: Amy.png
Baking order: Ξέρξης.png
Baking order: Xerxes.png
➜ isolated-test-set-persian cd ../isolated-test-set-emoji
➜ isolated-test-set-emoji archive-order-to-date-modified.sh test-en-spaces-fr-gr-emoji.zip
ERROR: No such file or directory
test-en-spaces-fr-gr-emoji-persian.zip
System ERROR:
Unknown error: -2147024894
Extracting archive: test-en-spaces-fr-gr-emoji.zip
Everything is Ok
Baking order:
➜ isolated-test-set-emoji
Yes, make sure to use the latest version. That was a brief bug earlier :)
Will do. Upgrade of pip will have to happen tomorrow as this requires an upgrade of Xcode too.
Calling it a night. Was a very exciting day. Thanks!
Installed dependencies
brew install pipx
pipx upgrade osxmetadata
Then make sure that your shell config (default on macOS now ~/.zshrc) contains ~/.local/bin in your PATH or else your pipx (Python Installer Package Virtual Environment) will not work.
export PATH="${PATH}:$HOME/.local/bin"
Tested
✅ All files have proper Unicode filenames. ✅ Allmost all files decompress and get order baked into comment and date-modified. ❌ But seq-nr and date-modified "run into different directions".
- First file in the archive should be nr 1 and youngest file.
- That's counter intuitive to reality where the first screen is by tendency the oldest.
- But we need that to work in harmony with Finder's "Clean Up By" which sorts "Date Modified" by youngest on top.
ℹ️ Ideally you can run the script with arguments:
- -n --comment-number-starting-at-first-file
- -N --comment-number-starting-at-last-file
- -m --date-modified-first-file-oldest
- -M --date-modified-first-file-youngest
Behavior:
- The opposing pairs -m and -M as well as -n and -N are each mutually exclusive.
- -n or -m can be combined
- If no args are submitted the script defaults to -nM (to fix what I marked with "❌")
Weekend finalization — My Hope 😉
My project: Your script outcome sets my starting point. And from then on I work additively/destructively with the files. Therefore I better wait for that last adaption, because my workflow allows no going back later. Hopefully we make that last mile.
And that would also be a quite good enough quality level for a good proof of concept / MVP which we can hand over to @aonez and he can decide whether to integrate that feature into Keka.
Just to confirm desired default behaviour:
- comments = ascending order = same as zip
- datestamps = descending order = opposite of zip
...is this correct?
Adding command-line arguments is a little tricky, a lot more code is needed, but it can be done with more time.
Regarding Keka: we should submit a new issue/feature-request with a succinct summary of required new feature "post-process extracted files with script", including what information we would like to be passed to the script (just filenames in zip order?).
Latest: https://gist.github.com/gingerbeardman/5239df9d087df952bf7ed054ed35b10c
-
Command line arguments: Thanks that you consider making these later.
-
For now just hardcoding the needed default is totally sufficient.
-
👍 Tested your script and it is exactly as proposed. Thanks a lot! 🙂 I can now get my project started.
➜ full-test-sets archive-order-to-date-modified.sh test-en-spaces-fr-gr.zip
Extracting archive: test-en-spaces-fr-gr.zip
Everything is Ok
Baking order 1: 01 this and that.png
Baking order 2: Emmanuel Jean-Michel Frédéric Macron.png
Baking order 3: Berlitz.png
Baking order 4: Amy.png
Baking order 5: Ξέρξης.png
Baking order 6: Xerxes.png
➜ full-test-sets ls -ltT test-en-spaces-fr-gr/
# Comment Nr inserted as I see them in Finder
1 -rw-r--r--@ 1 sn staff 31470 Dec 9 19:52:32 2021 01 this and that.png
2 -rw-r--r--@ 1 sn staff 37568 Dec 9 19:52:31 2021 Emmanuel Jean-Michel Frédéric Macron.png
3 -rw-r--r--@ 1 sn staff 28320 Dec 9 19:52:30 2021 Berlitz.png
4 -rw-r--r--@ 1 sn staff 27478 Dec 9 19:52:29 2021 Amy.png
5 -rw-r--r--@ 1 sn staff 45666 Dec 9 19:52:28 2021 Ξέρξης.png
6 -rw-r--r--@ 1 sn staff 28460 Dec 9 19:52:27 2021 Xerxes.png
Note:
- "Ascending" and "descending" is quite technical language when used in combination with various sorting formats. It is only immediately easily comprehensible for me with numbers. But concerning alphabet and timestamps or geo-positions etc it is already harder to understand it correctly, because "thinking everything as numeric expressions" is something developers may be sued too, but not we normal folks.
- Hence I prefer to express this is in a more human language:
- The default should be that the first file in the archive order has seq-nr 1 (and then ascends to higher numbers)
- and is the youngest file (so that is the highest amount of seconds since epoch-start, with elder files having a smaller second count, hence then the timestamps descending if I am not mistaken).
- Much more beautiful would have been this:
- The Date Modified shall be rounded to the next full minute.
- And the first file in archive gets nr1 and hh:mm:01 and nr2 gets hh:mm:02 and so on.
- Hence the index number is also encoded into the seconds as another visible queue:
File Nr Date Modified
05 1 19:13:01 # Second would correspond to nr. Beautiful!
Xing 2 19:13:02
Albert 3 19:13:03
02 4 19:13:04
❌ But sadly this would not work with Finder's hardcoded Icon order which if sorted by date modified is youngest file on top which would be the last file in archive order, which is not what we want.
- And also as the Finder does not display seconds (neither in list view, and not even in the "Get Info" dialog (CMD-I)) we would need to consider encoding into the minute, so the last file should be rounded to the previous minute and then each file before to the previous minute, and the seconds always being "00" which easily at a first glance tells you that were artificially created. Not in the Finder which doesn't show seconds, but in CLI environments or tools such as "A Better Finder Attributes".
- I'd like to know the design rationale of Apple why not to show the seconds, not even in the "Get Info" dialog (ironically the "file details" not being too detailed at all).
- I could file that new issue regarding the post-processing-scripting-environment for Keka regarding what variables should be available and what options for users, and you could then ammend the issue with the more technical requirements. Ok?
Reality is a bitch — Tried it with a real set, found another bug which did not manifest with our small set:
Something in that formula must be wrong or lead to wrong rounding:
touch -t $(echo "scale=2;$TOUCHSTAMP - $COUNTER/100" | bc -l)
@gingerbeardman please gimme an ETA for the fix of the math timestamp error (2 pix per sec instead of 1). To gimme a perspective and to decide whether I shall try my own luck with updating the TOUCHSTAMP formula or better wait for you as the DEV.
Change /100 to /10 and test.
Change /10 to /1 and test.
Let me know!
👎 $TOUCHSTAMP - $COUNTER/10
- From the 2nd file on the same timestamp is always repeated twice per file.
➜ Balsamiq archive-order-to-date-modified.sh EVM.zip
Extracting archive: EVM.zip
Everything is Ok
Baking order 1: OLD PARADIGMS.png
Baking order 2: old event creation 1.png
Baking order 3: old event creation 2.png
Baking order 4: old eventCal.png
Baking order 5: old evList.png
Baking order 6: old equipment rental 1.png
...
Baking order 153: 03b multi day.png
Baking order 154: 03b multi day_2.png
Baking order 155: 03b multi day_3.png
Baking order 156: 03a2 reset dialog.png
Baking order 157: 04a ALL.png
➜ Balsamiq mv EVM EVM-10
➜ Balsamiq ls -ltT EVM-10
19:30:36 2021 old eventCal.png
19:30:26 2021 OLD PARADIGMS.png
19:30:26 2021 old evList.png
19:30:16 2021 old equipment rental 1.png
19:30:16 2021 old event creation 1.png
19:30:06 2021 old equipment rental 2.png
19:30:06 2021 old event creation 2.png
19:29:56 2021 EVENT CAL LAYOUT.png
19:29:46 2021 evCal M Sep__.png
19:29:36 2021 evCal M Sep__ v.png
19:29:36 2021 evCal WW 36__ v.png
19:29:26 2021 EVENT CAL LIFECYCLE.png
19:29:26 2021 evCal CW 36__.png
19:29:16 2021 evCal 01a ROOMS.png
19:29:16 2021 evCal CW 36__ v.png
19:29:06 2021 evCal 01a2 dropdown.png
19:29:06 2021 evCal WW 36__.png
19:28:56 2021 evCal 01b hover over filled.png
19:28:46 2021 evCal 01c hover over empty.png
...
19:15:36 2021 03b multi day_2.png
19:15:26 2021 01 as dropdown.png
19:15:26 2021 03b multi day_3.png
19:15:16 2021 01 gaps title small.png
19:15:16 2021 03a2 reset dialog.png
19:15:06 2021 03b multi day.png
19:15:06 2021 04a ALL.png
Btw I love this "Everything is Ok" line. It always calms me down, however good or bad the state is 🙂 It's not coming from your script directly but from some of the apps you call. Whoever the author of that line may be, I love it! 😂
👎 $TOUCHSTAMP - $COUNTER/1
- From the 11th file on the same timestamp is always repeated twice per file.
- i.e. nr11 and nr12 both have 19:29:36
- Wheras the last 12 files are ok again.
- Someone good in mathematical series and sequences possibly smells the pattern and could guess the reason why.
➜ Balsamiq archive-order-to-date-modified.sh EVM.zip ## $TOUCHSTAMP - $COUNTER/1
Extracting archive: EVM.zip
Everything is Ok
Baking order 1: OLD PARADIGMS.png
Baking order 2: old event creation 1.png
Baking order 3: old event creation 2.png
Baking order 4: old eventCal.png
Baking order 5: old evList.png
...
Baking order 151: 01 as dropdown.png
Baking order 152: 01 gaps title small.png
Baking order 153: 03b multi day.png
Baking order 154: 03b multi day_2.png
Baking order 155: 03b multi day_3.png
Baking order 156: 03a2 reset dialog.png
Baking order 157: 04a ALL.png
➜ Balsamiq mv EVM EVM-1
➜ Balsamiq ls -ltT EVM-1
19:39:36 2021 evCal 02b4.png
19:38:36 2021 evCal 03 STATES no reserved.png
19:37:36 2021 EVENT LIST.png
19:36:36 2021 evList _.png
19:35:36 2021 evList v.png
19:34:36 2021 EVENT LIST BATCH.png
19:33:36 2021 evList batch 00a.png
19:32:36 2021 evList batch 00c.png
19:31:36 2021 evList batch 01a.png
19:30:36 2021 evList batch 01b.png
19:29:36 2021 OLD PARADIGMS.png
19:29:36 2021 evList batch 10a.png
19:28:36 2021 evList batch 10b.png
19:28:36 2021 old event creation 1.png
19:27:36 2021 EVENT PLANNER.png
19:27:36 2021 old event creation 2.png
19:26:36 2021 01 blank entirely.png
19:26:36 2021 old eventCal.png
19:25:36 2021 01b filled date.png
19:25:36 2021 old evList.png
19:24:36 2021 01d filled title in focus.png
19:24:36 2021 old equipment rental 1.png
19:23:36 2021 01x filled all but files.png
19:23:36 2021 old equipment rental 2.png
19:22:36 2021 01x2 multiday.png
19:22:36 2021 EVENT CAL LAYOUT.png
19:21:36 2021 01a abort dialog.png
19:21:36 2021 evCal M Sep__.png
19:20:36 2021 02a.png
19:20:36 2021 evCal M Sep__ v.png
19:19:36 2021 02a0.png
19:19:36 2021 evCal CW 36__.png
19:18:36 2021 02a1.png
19:18:36 2021 evCal CW 36__ v.png
19:17:36 2021 02b.png
19:17:36 2021 evCal WW 36__.png
19:16:36 2021 02b1.png
19:16:36 2021 evCal WW 36__ v.png
19:15:36 2021 02b2.png
19:15:36 2021 EVENT CAL LIFECYCLE.png
19:14:36 2021 02c.png
19:14:36 2021 evCal 01a ROOMS.png
19:13:36 2021 02c2.png
19:13:36 2021 evCal 01a2 dropdown.png
19:12:36 2021 02d.png
19:12:36 2021 evCal 01b hover over filled.png
19:11:36 2021 02d2.png
19:11:36 2021 evCal 01c hover over empty.png
19:10:36 2021 02d3.png
19:10:36 2021 evCal 01c3 tile+ empty.png
19:09:36 2021 02d4.png
19:09:36 2021 evCal 01c4 tile+ filled.png
19:08:36 2021 03 catering starts empty.png
19:08:36 2021 evCal 01c5 reserved.png
19:07:36 2021 03a chose drinksSnacks.png
19:07:36 2021 evCal 01c6 pending success.png
19:06:36 2021 03a1.png
19:06:36 2021 evCal 01c7 pending.png
19:05:36 2021 03a1b.png
19:05:36 2021 evCal 01c8 canceled success.png
19:04:36 2021 03a2.png
19:04:36 2021 evCal 01c9 approved.png
19:03:36 2021 03a2b.png
19:03:36 2021 evCal 02a ROOM.png
19:02:36 2021 03b2b1.png
19:02:36 2021 evCal 02a2 dropdown.png
19:01:36 2021 03b2b1a.png
19:01:36 2021 evCal 02b2 hover over filled.png
19:00:36 2021 03b2b1b.png
19:00:36 2021 evCal 02b3.png
18:59:36 2021 03a2 at least 1.png
18:58:36 2021 03ab.png
18:57:36 2021 04 possibilities.png
18:56:36 2021 04i impossible.png
18:55:36 2021 04n no repetition.png
18:54:36 2021 04w1 weekly for1 OK.png
18:53:36 2021 04w3 weekly for3 CONFLICTS.png
18:52:36 2021 04u3 weekly til3 1 OK.png
18:51:36 2021 04u4 weekly til4 2 CONFLICTS.png
18:50:36 2021 04u4b weekly til4 3 CONFLICTS.png
18:49:36 2021 04u4c weekly til4 MAX.png
18:48:36 2021 04a conflict.png
18:47:36 2021 04b resolutions.png
18:46:36 2021 04c resolved.png
18:45:36 2021 04d1 attribute hover.png
18:44:36 2021 04d2 attribute change.png
18:43:36 2021 04d3 attribute changed.png
18:42:36 2021 05d draft.png
18:41:36 2021 05d1 confirm reserve series.png
18:40:36 2021 05d2 confirm request series.png
18:39:36 2021 05e reserved.png
18:39:36 2021 EVENT CAL ALT LAYOUTS.png
18:38:36 2021 05e1 confirm cancel.png
18:38:36 2021 evCal as-is.png
18:37:36 2021 05p pending.png
18:37:36 2021 evCal rooms states.png
18:36:36 2021 EQUIPMENT.png
18:36:36 2021 evCal states sameLine.png
18:35:36 2021 evCal states sameLineBottom.png
18:35:36 2021 res 1 inventory.png
18:34:36 2021 evCal _date_ view today.png
18:34:36 2021 rsrc 2 add to shoppingcart.png
18:33:36 2021 evCal _date_ roomStates.png
18:33:36 2021 rsrc 3a checkout.png
18:32:36 2021 evCal 2020__ •Sep__ Today.png
18:32:36 2021 rsrc 3b final filling.png
18:31:36 2021 evCal 2020__ •36__ Today.png
18:31:36 2021 rsrc 4 success.png
18:30:36 2021 evCal 2020__ •W36__ Today.png
18:30:36 2021 resEvent 1a.png
18:29:36 2021 -- OUT OF SCOPE --.png
18:29:36 2021 evCal 2020__ Week 40__ Today.png
18:28:36 2021 SINGLE SCREENS.png
18:28:36 2021 evCal 2020__ Week 40__ Today bgW.png
18:27:36 2021 evCal 01b2 touched.png
18:27:36 2021 evList batch 02x.png
18:26:36 2021 evCal WW 36__ Tablet.png
18:26:36 2021 evList batch 02y.png
18:25:36 2021 05p1.png
18:25:36 2021 DISCARDED SINGLE SCREENS.png
18:24:36 2021 evCal 01d aborted.png
18:24:36 2021 evList batch 00b X.png
18:23:36 2021 evList _ aborted.png
18:23:36 2021 evList batch 01c X.png
18:22:36 2021 01 w resp layout header redesigned.png
18:22:36 2021 EVENT TILE TINY.png
18:21:36 2021 01 dense.png
18:21:36 2021 evCal 01c3 tile empty.png
18:20:36 2021 01 as 3 radio buttons.png
18:20:36 2021 evCal 01c4 tile filled.png
18:19:36 2021 01 as dropdown.png
18:19:36 2021 EQUIPMENT for EVENT.png
18:18:36 2021 01 gaps title small.png
18:18:36 2021 resEvtSearch 1a.png
18:17:36 2021 03b multi day.png
18:17:36 2021 resEvtSearch 1b0.png
18:16:36 2021 03b multi day_2.png
18:16:36 2021 resEvtSearch 1b1.png
18:15:36 2021 03b multi day_3.png
18:15:36 2021 resEvtSearch 1b4.png
18:14:36 2021 03a2 reset dialog.png
18:14:36 2021 resEvent 02a.png
18:13:36 2021 04a ALL.png
18:13:36 2021 resEvent 02b.png
18:12:36 2021 resEvent 03a.png
18:11:36 2021 resEvent 03b.png
18:10:36 2021 EVENTS as CAL or LIST.png
18:09:36 2021 ev 1a calendar.png
18:08:36 2021 ev 1a2 dropdown.png
18:07:36 2021 ev 1b list.png
18:06:36 2021 ev 1b2 dropdown.png
18:05:36 2021 ev 2b pag size.png
18:04:36 2021 ev 2b2 dropdown.png
18:03:36 2021 ev 2c pag 2L.png
18:02:36 2021 ev 2z pag full.png
18:01:36 2021 ev 2c list tablet.png
18:00:36 2021 -- DISCARDED --.png
@gingerbeardman Please gimme a first reaction on the /10 and /100 attempts. Thanks!
Else it looks that I will need to go with my own desperate scripting skills…
Add these lines before touch line, to see debug information:
echo $TOUCHSTAMP
echo $COUNTER
echo $(echo "scale=2;$TOUCHSTAMP - $COUNTER/100" | bc -l)
We need to figure out the correct formula for the the time of each file, to replace $TOUCHSTAMP - $COUNTER/100 in the script
For /1 and /10 and /100 the patterns of failure are anyhow documented.
I will add the echo output. But only when attempting new formulas.
So it's on me to figure out the correct formula or the proper rounding for bc, whatever the cause for this is.
I was hoping that you have a clue.
One more possible cause for failure touch -t maybe has some kind of "correct inconsistent timestamps" mechanism/mode which works not in our favor.
So getting the debug output may actually helps us to rule that out. Will first make a dry run mode which only puts out "nr timestamp filename" and does not execute osxmetadata touch to see whether this data is in order.
Only then we can start the next round of bug tracing.
Ok, I have the bug. Our formula calculates with base100, but we are calculating seconds or minutes, which are both base60.
https://gist.github.com/porg/258bcd052d84c05c3ff430f9e90cb24c
Therefore regardless of whether minutes or seconds, second or minute 61-99 never exist, but must be squeezed/rounded into 00-59, hence we statistically always "have about 2 collisions" per one time unit. And therefore always a few files (the ones counting down until the 00 barrier) always were right. And then the errors started occurring (as soon as the 99 was reached in the countdown again).
Debug Output
$ archive-order-to-date-modified.sh EVM.zip
Extracting archive: EVM.zip
Everything is Ok
OUT DIR: EVM
DATESTAMP: Thu Dec 9 19:30:36 CET 2021
TOUCHSTAMP: 202112091930.36
FILE AMOUNT: 157
PROCESSING FILES
COUNTER TOUCHSTAMP FILE
1 202112091930.35 OLD PARADIGMS.png
2 202112091930.34 old event creation 1.png
3 202112091930.33 old event creation 2.png
4 202112091930.32 old eventCal.png
5 202112091930.31 old evList.png
6 202112091930.30 old equipment rental 1.png
7 202112091930.29 old equipment rental 2.png
8 202112091930.28 EVENT CAL LAYOUT.png
9 202112091930.27 evCal M Sep__.png
10 202112091930.26 evCal M Sep__ v.png
11 202112091930.25 evCal CW 36__.png
12 202112091930.24 evCal CW 36__ v.png
13 202112091930.23 evCal WW 36__.png
14 202112091930.22 evCal WW 36__ v.png
15 202112091930.21 EVENT CAL LIFECYCLE.png
16 202112091930.20 evCal 01a ROOMS.png
17 202112091930.19 evCal 01a2 dropdown.png
18 202112091930.18 evCal 01b hover over filled.png
19 202112091930.17 evCal 01c hover over empty.png
20 202112091930.16 evCal 01c3 tile+ empty.png
21 202112091930.15 evCal 01c4 tile+ filled.png
22 202112091930.14 evCal 01c5 reserved.png
23 202112091930.13 evCal 01c6 pending success.png
24 202112091930.12 evCal 01c7 pending.png
25 202112091930.11 evCal 01c8 canceled success.png
26 202112091930.10 evCal 01c9 approved.png
27 202112091930.09 evCal 02a ROOM.png
28 202112091930.08 evCal 02a2 dropdown.png
29 202112091930.07 evCal 02b2 hover over filled.png
30 202112091930.06 evCal 02b3.png
31 202112091930.05 evCal 02b4.png
32 202112091930.04 evCal 03 STATES no reserved.png
33 202112091930.03 EVENT LIST.png
34 202112091930.02 evList _.png
35 202112091930.01 evList v.png
36 202112091930.00 EVENT LIST BATCH.png
37 202112091929.99 evList batch 00a.png
38 202112091929.98 evList batch 00c.png
39 202112091929.97 evList batch 01a.png
40 202112091929.96 evList batch 01b.png
41 202112091929.95 evList batch 10a.png
42 202112091929.94 evList batch 10b.png
43 202112091929.93 EVENT PLANNER.png
44 202112091929.92 01 blank entirely.png
45 202112091929.91 01b filled date.png
46 202112091929.90 01d filled title in focus.png
47 202112091929.89 01x filled all but files.png
48 202112091929.88 01x2 multiday.png
49 202112091929.87 01a abort dialog.png
50 202112091929.86 02a.png
51 202112091929.85 02a0.png
52 202112091929.84 02a1.png
53 202112091929.83 02b.png
54 202112091929.82 02b1.png
55 202112091929.81 02b2.png
56 202112091929.80 02c.png
57 202112091929.79 02c2.png
58 202112091929.78 02d.png
59 202112091929.77 02d2.png
60 202112091929.76 02d3.png
61 202112091929.75 02d4.png
62 202112091929.74 03 catering starts empty.png
63 202112091929.73 03a chose drinksSnacks.png
64 202112091929.72 03a1.png
65 202112091929.71 03a1b.png
66 202112091929.70 03a2.png
67 202112091929.69 03a2b.png
68 202112091929.68 03b2b1.png
69 202112091929.67 03b2b1a.png
70 202112091929.66 03b2b1b.png
71 202112091929.65 03a2 at least 1.png
72 202112091929.64 03ab.png
73 202112091929.63 04 possibilities.png
74 202112091929.62 04i impossible.png
75 202112091929.61 04n no repetition.png
76 202112091929.60 04w1 weekly for1 OK.png
77 202112091929.59 04w3 weekly for3 CONFLICTS.png
78 202112091929.58 04u3 weekly til3 1 OK.png
79 202112091929.57 04u4 weekly til4 2 CONFLICTS.png
80 202112091929.56 04u4b weekly til4 3 CONFLICTS.png
81 202112091929.55 04u4c weekly til4 MAX.png
82 202112091929.54 04a conflict.png
83 202112091929.53 04b resolutions.png
84 202112091929.52 04c resolved.png
85 202112091929.51 04d1 attribute hover.png
86 202112091929.50 04d2 attribute change.png
87 202112091929.49 04d3 attribute changed.png
88 202112091929.48 05d draft.png
89 202112091929.47 05d1 confirm reserve series.png
90 202112091929.46 05d2 confirm request series.png
91 202112091929.45 05e reserved.png
92 202112091929.44 05e1 confirm cancel.png
93 202112091929.43 05p pending.png
94 202112091929.42 EQUIPMENT.png
95 202112091929.41 res 1 inventory.png
96 202112091929.40 rsrc 2 add to shoppingcart.png
97 202112091929.39 rsrc 3a checkout.png
98 202112091929.38 rsrc 3b final filling.png
99 202112091929.37 rsrc 4 success.png
100 202112091929.36 resEvent 1a.png
101 202112091929.35 -- OUT OF SCOPE --.png
102 202112091929.34 SINGLE SCREENS.png
103 202112091929.33 evCal 01b2 touched.png
104 202112091929.32 evCal WW 36__ Tablet.png
105 202112091929.31 05p1.png
106 202112091929.30 evCal 01d aborted.png
107 202112091929.29 evList _ aborted.png
108 202112091929.28 EVENT TILE TINY.png
109 202112091929.27 evCal 01c3 tile empty.png
110 202112091929.26 evCal 01c4 tile filled.png
111 202112091929.25 EQUIPMENT for EVENT.png
112 202112091929.24 resEvtSearch 1a.png
113 202112091929.23 resEvtSearch 1b0.png
114 202112091929.22 resEvtSearch 1b1.png
115 202112091929.21 resEvtSearch 1b4.png
116 202112091929.20 resEvent 02a.png
117 202112091929.19 resEvent 02b.png
118 202112091929.18 resEvent 03a.png
119 202112091929.17 resEvent 03b.png
120 202112091929.16 EVENTS as CAL or LIST.png
121 202112091929.15 ev 1a calendar.png
122 202112091929.14 ev 1a2 dropdown.png
123 202112091929.13 ev 1b list.png
124 202112091929.12 ev 1b2 dropdown.png
125 202112091929.11 ev 2b pag size.png
126 202112091929.10 ev 2b2 dropdown.png
127 202112091929.09 ev 2c pag 2L.png
128 202112091929.08 ev 2z pag full.png
129 202112091929.07 ev 2c list tablet.png
130 202112091929.06 -- DISCARDED --.png
131 202112091929.05 EVENT CAL ALT LAYOUTS.png
132 202112091929.04 evCal as-is.png
133 202112091929.03 evCal rooms states.png
134 202112091929.02 evCal states sameLine.png
135 202112091929.01 evCal states sameLineBottom.png
136 202112091929.00 evCal _date_ view today.png
137 202112091928.99 evCal _date_ roomStates.png
138 202112091928.98 evCal 2020__ •Sep__ Today.png
139 202112091928.97 evCal 2020__ •36__ Today.png
140 202112091928.96 evCal 2020__ •W36__ Today.png
141 202112091928.95 evCal 2020__ Week 40__ Today.png
142 202112091928.94 evCal 2020__ Week 40__ Today bgW.png
143 202112091928.93 evList batch 02x.png
144 202112091928.92 evList batch 02y.png
145 202112091928.91 DISCARDED SINGLE SCREENS.png
146 202112091928.90 evList batch 00b X.png
147 202112091928.89 evList batch 01c X.png
148 202112091928.88 01 w resp layout header redesigned.png
149 202112091928.87 01 dense.png
150 202112091928.86 01 as 3 radio buttons.png
151 202112091928.85 01 as dropdown.png
152 202112091928.84 01 gaps title small.png
153 202112091928.83 03b multi day.png
154 202112091928.82 03b multi day_2.png
155 202112091928.81 03b multi day_3.png
156 202112091928.80 03a2 reset dialog.png
157 202112091928.79 04a ALL.png
The fix will be something with modulo. But no immediate idea how to do this in a Shell environment.
I did the QA and analytics, the problem solving will be your treat 👍 that's our role play 😉
My proposal: Just use the unix timestamp format inside the loop (seconds since epoch start) then we can dumbly substract and the conversion into the needed format happens later with the tool which sets the moddate (touch or SetFile).
I estimate this would take me another 45min (like the analysis did). How fast could you do it?
I however have no clue however about timezones in archives etc. So maybe it is better to finish the script with the intents you had.
Fixed it: https://gist.github.com/porg/258bcd052d84c05c3ff430f9e90cb24c
- Luckily you used the timestamp of the ZIP archive as it is in the filesystem.
- Thought you use something more sophisticated like the creation time as of the whole archive as specified in the archive manifest or the timestamp of the first file in the archive if encoded in the archive.
- So no timezone interpretation/conversion necessary.
Verbose Output
Last login: Wed Dec 15 18:44:50 on ttys001
$ archive-order-to-date-modified.sh EVM.zip
Extracting archive: EVM.zip
Everything is Ok
Files in archive: 157
Date Stamp: Thu Dec 9 19:30:36 CET 2021
Touch Stamp: 202112091930.36
Unix Stamp: 1639074636
File order in archive will be baked into metadata of extracted files:
- Finder comment gets sequence number
- Modification date will be created artificially
- First file in archive gets same mod-date as archive
- Next file each will be one second younger than the previous file
Extracting files...
Nr Unix Date YYYY-MM-DD hh:mm:ss File
1 1639074636 2021-12-09 19:30:36 OLD PARADIGMS.png
2 1639074635 2021-12-09 19:30:35 old event creation 1.png
3 1639074634 2021-12-09 19:30:34 old event creation 2.png
4 1639074633 2021-12-09 19:30:33 old eventCal.png
5 1639074632 2021-12-09 19:30:32 old evList.png
6 1639074631 2021-12-09 19:30:31 old equipment rental 1.png
7 1639074630 2021-12-09 19:30:30 old equipment rental 2.png
8 1639074629 2021-12-09 19:30:29 EVENT CAL LAYOUT.png
9 1639074628 2021-12-09 19:30:28 evCal M Sep__.png
10 1639074627 2021-12-09 19:30:27 evCal M Sep__ v.png
11 1639074626 2021-12-09 19:30:26 evCal CW 36__.png
12 1639074625 2021-12-09 19:30:25 evCal CW 36__ v.png
13 1639074624 2021-12-09 19:30:24 evCal WW 36__.png
14 1639074623 2021-12-09 19:30:23 evCal WW 36__ v.png
15 1639074622 2021-12-09 19:30:22 EVENT CAL LIFECYCLE.png
16 1639074621 2021-12-09 19:30:21 evCal 01a ROOMS.png
17 1639074620 2021-12-09 19:30:20 evCal 01a2 dropdown.png
18 1639074619 2021-12-09 19:30:19 evCal 01b hover over filled.png
19 1639074618 2021-12-09 19:30:18 evCal 01c hover over empty.png
20 1639074617 2021-12-09 19:30:17 evCal 01c3 tile+ empty.png
21 1639074616 2021-12-09 19:30:16 evCal 01c4 tile+ filled.png
22 1639074615 2021-12-09 19:30:15 evCal 01c5 reserved.png
23 1639074614 2021-12-09 19:30:14 evCal 01c6 pending success.png
24 1639074613 2021-12-09 19:30:13 evCal 01c7 pending.png
25 1639074612 2021-12-09 19:30:12 evCal 01c8 canceled success.png
26 1639074611 2021-12-09 19:30:11 evCal 01c9 approved.png
27 1639074610 2021-12-09 19:30:10 evCal 02a ROOM.png
28 1639074609 2021-12-09 19:30:09 evCal 02a2 dropdown.png
29 1639074608 2021-12-09 19:30:08 evCal 02b2 hover over filled.png
30 1639074607 2021-12-09 19:30:07 evCal 02b3.png
31 1639074606 2021-12-09 19:30:06 evCal 02b4.png
32 1639074605 2021-12-09 19:30:05 evCal 03 STATES no reserved.png
33 1639074604 2021-12-09 19:30:04 EVENT LIST.png
34 1639074603 2021-12-09 19:30:03 evList _.png
35 1639074602 2021-12-09 19:30:02 evList v.png
36 1639074601 2021-12-09 19:30:01 EVENT LIST BATCH.png
37 1639074600 2021-12-09 19:30:00 evList batch 00a.png
38 1639074599 2021-12-09 19:29:59 evList batch 00c.png
39 1639074598 2021-12-09 19:29:58 evList batch 01a.png
40 1639074597 2021-12-09 19:29:57 evList batch 01b.png
41 1639074596 2021-12-09 19:29:56 evList batch 10a.png
42 1639074595 2021-12-09 19:29:55 evList batch 10b.png
43 1639074594 2021-12-09 19:29:54 EVENT PLANNER.png
44 1639074593 2021-12-09 19:29:53 01 blank entirely.png
45 1639074592 2021-12-09 19:29:52 01b filled date.png
46 1639074591 2021-12-09 19:29:51 01d filled title in focus.png
47 1639074590 2021-12-09 19:29:50 01x filled all but files.png
48 1639074589 2021-12-09 19:29:49 01x2 multiday.png
49 1639074588 2021-12-09 19:29:48 01a abort dialog.png
50 1639074587 2021-12-09 19:29:47 02a.png
51 1639074586 2021-12-09 19:29:46 02a0.png
52 1639074585 2021-12-09 19:29:45 02a1.png
53 1639074584 2021-12-09 19:29:44 02b.png
54 1639074583 2021-12-09 19:29:43 02b1.png
55 1639074582 2021-12-09 19:29:42 02b2.png
56 1639074581 2021-12-09 19:29:41 02c.png
57 1639074580 2021-12-09 19:29:40 02c2.png
58 1639074579 2021-12-09 19:29:39 02d.png
59 1639074578 2021-12-09 19:29:38 02d2.png
60 1639074577 2021-12-09 19:29:37 02d3.png
61 1639074576 2021-12-09 19:29:36 02d4.png
62 1639074575 2021-12-09 19:29:35 03 catering starts empty.png
63 1639074574 2021-12-09 19:29:34 03a chose drinksSnacks.png
64 1639074573 2021-12-09 19:29:33 03a1.png
65 1639074572 2021-12-09 19:29:32 03a1b.png
66 1639074571 2021-12-09 19:29:31 03a2.png
67 1639074570 2021-12-09 19:29:30 03a2b.png
68 1639074569 2021-12-09 19:29:29 03b2b1.png
69 1639074568 2021-12-09 19:29:28 03b2b1a.png
70 1639074567 2021-12-09 19:29:27 03b2b1b.png
71 1639074566 2021-12-09 19:29:26 03a2 at least 1.png
72 1639074565 2021-12-09 19:29:25 03ab.png
73 1639074564 2021-12-09 19:29:24 04 possibilities.png
74 1639074563 2021-12-09 19:29:23 04i impossible.png
75 1639074562 2021-12-09 19:29:22 04n no repetition.png
76 1639074561 2021-12-09 19:29:21 04w1 weekly for1 OK.png
77 1639074560 2021-12-09 19:29:20 04w3 weekly for3 CONFLICTS.png
78 1639074559 2021-12-09 19:29:19 04u3 weekly til3 1 OK.png
79 1639074558 2021-12-09 19:29:18 04u4 weekly til4 2 CONFLICTS.png
80 1639074557 2021-12-09 19:29:17 04u4b weekly til4 3 CONFLICTS.png
81 1639074556 2021-12-09 19:29:16 04u4c weekly til4 MAX.png
82 1639074555 2021-12-09 19:29:15 04a conflict.png
83 1639074554 2021-12-09 19:29:14 04b resolutions.png
84 1639074553 2021-12-09 19:29:13 04c resolved.png
85 1639074552 2021-12-09 19:29:12 04d1 attribute hover.png
86 1639074551 2021-12-09 19:29:11 04d2 attribute change.png
87 1639074550 2021-12-09 19:29:10 04d3 attribute changed.png
88 1639074549 2021-12-09 19:29:09 05d draft.png
89 1639074548 2021-12-09 19:29:08 05d1 confirm reserve series.png
90 1639074547 2021-12-09 19:29:07 05d2 confirm request series.png
91 1639074546 2021-12-09 19:29:06 05e reserved.png
92 1639074545 2021-12-09 19:29:05 05e1 confirm cancel.png
93 1639074544 2021-12-09 19:29:04 05p pending.png
94 1639074543 2021-12-09 19:29:03 EQUIPMENT.png
95 1639074542 2021-12-09 19:29:02 res 1 inventory.png
96 1639074541 2021-12-09 19:29:01 rsrc 2 add to shoppingcart.png
97 1639074540 2021-12-09 19:29:00 rsrc 3a checkout.png
98 1639074539 2021-12-09 19:28:59 rsrc 3b final filling.png
99 1639074538 2021-12-09 19:28:58 rsrc 4 success.png
100 1639074537 2021-12-09 19:28:57 resEvent 1a.png
101 1639074536 2021-12-09 19:28:56 -- OUT OF SCOPE --.png
102 1639074535 2021-12-09 19:28:55 SINGLE SCREENS.png
103 1639074534 2021-12-09 19:28:54 evCal 01b2 touched.png
104 1639074533 2021-12-09 19:28:53 evCal WW 36__ Tablet.png
105 1639074532 2021-12-09 19:28:52 05p1.png
106 1639074531 2021-12-09 19:28:51 evCal 01d aborted.png
107 1639074530 2021-12-09 19:28:50 evList _ aborted.png
108 1639074529 2021-12-09 19:28:49 EVENT TILE TINY.png
109 1639074528 2021-12-09 19:28:48 evCal 01c3 tile empty.png
110 1639074527 2021-12-09 19:28:47 evCal 01c4 tile filled.png
111 1639074526 2021-12-09 19:28:46 EQUIPMENT for EVENT.png
112 1639074525 2021-12-09 19:28:45 resEvtSearch 1a.png
113 1639074524 2021-12-09 19:28:44 resEvtSearch 1b0.png
114 1639074523 2021-12-09 19:28:43 resEvtSearch 1b1.png
115 1639074522 2021-12-09 19:28:42 resEvtSearch 1b4.png
116 1639074521 2021-12-09 19:28:41 resEvent 02a.png
117 1639074520 2021-12-09 19:28:40 resEvent 02b.png
118 1639074519 2021-12-09 19:28:39 resEvent 03a.png
119 1639074518 2021-12-09 19:28:38 resEvent 03b.png
120 1639074517 2021-12-09 19:28:37 EVENTS as CAL or LIST.png
121 1639074516 2021-12-09 19:28:36 ev 1a calendar.png
122 1639074515 2021-12-09 19:28:35 ev 1a2 dropdown.png
123 1639074514 2021-12-09 19:28:34 ev 1b list.png
124 1639074513 2021-12-09 19:28:33 ev 1b2 dropdown.png
125 1639074512 2021-12-09 19:28:32 ev 2b pag size.png
126 1639074511 2021-12-09 19:28:31 ev 2b2 dropdown.png
127 1639074510 2021-12-09 19:28:30 ev 2c pag 2L.png
128 1639074509 2021-12-09 19:28:29 ev 2z pag full.png
129 1639074508 2021-12-09 19:28:28 ev 2c list tablet.png
130 1639074507 2021-12-09 19:28:27 -- DISCARDED --.png
131 1639074506 2021-12-09 19:28:26 EVENT CAL ALT LAYOUTS.png
132 1639074505 2021-12-09 19:28:25 evCal as-is.png
133 1639074504 2021-12-09 19:28:24 evCal rooms states.png
134 1639074503 2021-12-09 19:28:23 evCal states sameLine.png
135 1639074502 2021-12-09 19:28:22 evCal states sameLineBottom.png
136 1639074501 2021-12-09 19:28:21 evCal _date_ view today.png
137 1639074500 2021-12-09 19:28:20 evCal _date_ roomStates.png
138 1639074499 2021-12-09 19:28:19 evCal 2020__ •Sep__ Today.png
139 1639074498 2021-12-09 19:28:18 evCal 2020__ •36__ Today.png
140 1639074497 2021-12-09 19:28:17 evCal 2020__ •W36__ Today.png
141 1639074496 2021-12-09 19:28:16 evCal 2020__ Week 40__ Today.png
142 1639074495 2021-12-09 19:28:15 evCal 2020__ Week 40__ Today bgW.png
143 1639074494 2021-12-09 19:28:14 evList batch 02x.png
144 1639074493 2021-12-09 19:28:13 evList batch 02y.png
145 1639074492 2021-12-09 19:28:12 DISCARDED SINGLE SCREENS.png
146 1639074491 2021-12-09 19:28:11 evList batch 00b X.png
147 1639074490 2021-12-09 19:28:10 evList batch 01c X.png
148 1639074489 2021-12-09 19:28:09 01 w resp layout header redesigned.png
149 1639074488 2021-12-09 19:28:08 01 dense.png
150 1639074487 2021-12-09 19:28:07 01 as 3 radio buttons.png
151 1639074486 2021-12-09 19:28:06 01 as dropdown.png
152 1639074485 2021-12-09 19:28:05 01 gaps title small.png
153 1639074484 2021-12-09 19:28:04 03b multi day.png
154 1639074483 2021-12-09 19:28:03 03b multi day_2.png
155 1639074482 2021-12-09 19:28:02 03b multi day_3.png
156 1639074481 2021-12-09 19:28:01 03a2 reset dialog.png
157 1639074480 2021-12-09 19:28:00 04a ALL.png
Despite the Terminal output being all right in Finder it still is not all right. Am investigating.
Ok, was just a sloppy mistake. Did not adapt the actual touch -t line. Will have that in a few minutes.
✅ Final version for me: archive-order-to-metadata.sh
- Encodes both to creation and modification date for ultimate perserverance
- Edit your image files (and hence change the modification date) but nevertheless keep the possibility to sort by creation-date and as such the intended screen order.
- Uses
SetFilewhich ships with Xcode CLI tools (xcode-select --install)- Added to dependency info
- You can even insert files into your screen series
- in List View by seq-nr like 3 4 4b 4c 5
- or in icon view my sorting:none simply by visual arrangement.
Cool! Nice work. I don't know how I missed the 60 second thing. Good spot.
I have kids, so today I had no time at my computer.
SetFile is not advised to be used (it will disappear with a forthcoming version of macOS/Xcode, although they have been saying that since Xcode 6)
Thanks. Know another tool/way than SetFile to set the creation date via command line?
Hint to users: In case you want to extract all ZIPs in a folder with our script use this:
cd /path/to/dir-holding-ZIPs/ ; find . -type f -name "*.zip" -exec archive-order-to-metadata.sh {} \;
-
cdat the beginning because the target of archive-order-to-metadata.sh is your current working directory -
findrecursively loops through all *.zip files - and for each encountered ZIP file executes
archive-order-to-metadata.sh
✅ Deluxe version: archive-order-to-metadata.sh with these new features:
- Hiding file extension on all extracted files
- Setting creation and modification date of output directory to that of the archive
Learning for me: Variable $CREATIONSTAMP in script root scope (shell environment I assume) gets passed into while loop but $CREATIONSTAMP manipulated inside that loop has its own scope and gets not passed out to the script root scope.
Thanks. Know another tool/way than
SetFileto set the creation date via command line?
Check this answer https://apple.stackexchange.com/a/187673