Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PowerRename creates wrong Time using $hh$mm$ss code in replacement string #38218

Open
Rolf4902 opened this issue Mar 28, 2025 · 5 comments
Open
Labels
Issue-Bug Something isn't working Needs-Team-Response An issue author responded so the team needs to follow up Needs-Triage For issues raised to be triaged and prioritized by internal Microsoft teams

Comments

@Rolf4902
Copy link

Rolf4902 commented Mar 28, 2025

Microsoft PowerToys version

v0.89.0

Installation method

PowerToys auto-update

Running as admin

No

Area(s) with issue?

PowerRename

Steps to reproduce

Some files are provided

✔️ Expected Behavior

Defining a replacement string $YY$MM$DD-$hh$mm$ss should derive the correct time from the original file.

Extract from the original folder, just 3 files only. The latter two were taken within one second:

141_PANA.zip

The usage was to rename picture files copied from a SD-Card to folder TestRename on a disk. While trying to reset the file name as composed in camera to a Timestamp name the issue was detected.
Reason for the issue might be, that the camera shot several pictures within a second. Note that cameras today can make up to 20 or more pictures in one second. The Rename-program might detect that there will be a naming conflict with duplicate filenames and tries to avoid this by modifying the base name, but this fails. And this isn’t IMHO a good approach.
Years ago I wrote as a training task a Powershell script. which does much more that just renaming. It allocates automatically owning folders per day, copies the correct files with rename to the appropriate folders and much more.
In case a naming conflict is detected for several files shot within one second, I assign to the new name an extension -nn, which is -02, -03, -04 and so forth. I start first with -02. When the timestamp changes and the name conflict no longer occurs I rename the first File of the previous group to ...-01, such I have the files later properly sorted in the Explorer views, Open-Forms in applications and so forth.

See how a reasonable rename for this type of data looks like:

Image

Regards to Chris: A very clever application

❌ Actual Behavior

Defining a replacement string $YY$MM$DD-$hh$mm$ss doesn't derive the correct time from the original file. It looks like the time of the first element is used which is folder RAWS!

Image

Other Software

No response

@Rolf4902 Rolf4902 added Issue-Bug Something isn't working Needs-Triage For issues raised to be triaged and prioritized by internal Microsoft teams labels Mar 28, 2025
@moooyo
Copy link
Contributor

moooyo commented Mar 31, 2025

I cannot repro this issues with your files.
Use your format string I got the results below
Image

And, the 'Raws folder's date' you mentioned seems is the modified date. But at least now, the date we use is created date. @Rolf4902

@moooyo moooyo added Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something and removed Needs-Triage For issues raised to be triaged and prioritized by internal Microsoft teams labels Mar 31, 2025
@Rolf4902
Copy link
Author

Timestamps of files are in WIndows tricky: we have a FILE CREATION (1) Timestamp, FILE MODDIFICATION (2) Timestamp and LAST ACCESS (3) Timestamp.

(1) is set by the OS when the file enters the file system. This can be in an application as SAVE or SAVE AS moment or any other programme writes a NEW file, e. g. exctracting a zip-file. (2) is set or modified when a existing file was modified and saved. (3) is important mainly for files on servers which allows server managers to determine if any files are still used e. g. to export them onto slower and cheaper disks or other archive systems on tape etc. (2) is the default timestamp shown in Explorer lists, the others can be added on demand.

Special for picture data is that (1) is not only a file-system attribute but is also contained in the EXIF-data of the file. Now when we copy such files from an SD-card of a camera or from a smartphone (1) is set by WIndows to the current time of the PC, but (2) is left as set by the camera. And even when we modify a picture file in any application on the PC and save the results (2) in the EXIF data is left unchanged, while the last modified attribute data in the OS are set.

Such we have only once(!) a chance to set reliably the file NAME according the timestamp of the moment the picture was shot is when we have copied the files from the source (SD | Smartphone) to the disk of the PC. Because in that moment (2) is identical to the timestamp-data in the EXIF-Part of the picture data. This consistancy can't be guaranteed later on.

Now PowerRename takes just the timestamp (1) of the files:

Image

We see a problem with duplicate files names because all files have the timestamp of extracting the zip-archive.

As I explained above FileCreation for me is the timestamp of the file in the camera. I now know that this timestamp is reset to the system time when the file is copied to disk. I wasn't aware of this because the Powershell script mentioned above uses the (2) of the file on the SD-card.

Can PowerRename work on the files on the SD-card? Here's a collection of files just created and shown in Explorer:

Image

All pictures are shot within the same minute. The first 4 are regular shots, the rest are made in burst mode of the camera making several pictures within one second. How is PowerRename working?

Image

We see that duplicate names are composed! Pressing the Apply button freezes the program and must be killed using the Task Manager. But it had composed file names not shown in the preview and renamed all files. However, I'm not happy with the composed names.

Currently we have using the dir command in a cmd-Terminal-Window

 Verzeichnis von K:\DCIM\141_PANA

27.03.2025  19:13    <DIR>          .
27.03.2025  19:13    <DIR>          ..
31.03.2025  12:20         7.220.736 IMG-250331-122010.JPG
31.03.2025  12:20         4.861.440 IMG-250331-122014.JPG
31.03.2025  12:20         4.992.512 IMG-250331-122017.JPG
31.03.2025  12:20         5.388.800 IMG-250331-122021.JPG
31.03.2025  12:20         4.512.768 IMG-250331-122027.JPG
31.03.2025  12:20         4.493.824 IMG-250331-122027 (2).JPG
31.03.2025  12:20         4.500.992 IMG-250331-122027 (3).JPG
31.03.2025  12:20         4.463.616 IMG-250331-122027 (4).JPG
31.03.2025  12:20         4.495.872 IMG-250331-122028.JPG
31.03.2025  12:20         4.481.024 IMG-250331-122027 (5).JPG

While Explorer sorts the first file of the burst group behind the others:

Image

I still think it is preferrable to build names in that form:

31.03.2025  12:20         4.512.768 IMG-250331-122027-01.JPG
31.03.2025  12:20         4.493.824 IMG-250331-122027-02.JPG
31.03.2025  12:20         4.500.992 IMG-250331-122027-02.JPG
31.03.2025  12:20         4.463.616 IMG-250331-122027-04.JPG
31.03.2025  12:20         4.495.872 IMG-250331-122028.JPG
31.03.2025  12:20         4.481.024 IMG-250331-122027-05.JPG

We better see the group of files belonging together, we can handle up to 99 files within one second.

Two issues:

There should be a toggle provided to set either CreationDate OR ModificationDate as Basis for the new name composition.

Handling duplicate file names to be improved. An example is described and shown at the begin of this thread.

@microsoft-github-policy-service microsoft-github-policy-service bot added Needs-Triage For issues raised to be triaged and prioritized by internal Microsoft teams Needs-Team-Response An issue author responded so the team needs to follow up and removed Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something labels Mar 31, 2025
@Rolf4902
Copy link
Author

Rolf4902 commented Mar 31, 2025

Algorithm for processing duplicate names:

image

@moooyo
Copy link
Contributor

moooyo commented Apr 1, 2025

Seems your feature request is same as #38186.

The original ask you want is to chose Created Date/Modified Date/EXIF Date.

The dup name seems that it's a system behaviour. Need more investigation.

@Rolf4902
Copy link
Author

Rolf4902 commented Apr 1, 2025

Yes, the mentioned request is quite identical with mine, but I do not expect using in addition EXIF data.
People sometimes require this for reorganisation of an existing data stock, but there might be so called "side car" files around and others. This will be quite complicated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Bug Something isn't working Needs-Team-Response An issue author responded so the team needs to follow up Needs-Triage For issues raised to be triaged and prioritized by internal Microsoft teams
Projects
None yet
Development

No branches or pull requests

2 participants