Multi-Rename Tool:Date and Time

[Fla$her]

So did I and contrary to your apparent reservations and objections I fully support his proposal.

He, like you, did not give a methodology for how two or more types of operations should be performed simultaneously and even sequentially within the same interface, i.e. what I wrote above, but judging by the answers, you did not understand. And he did not explain why, at the same time, this dialog should leave the same name/title, unrelated to editing metadata.

No clue what might be that difficult to understand about the term "standardizing their time-stamps to the full hour".

The use of the concept of "standardizing ... to". There is a more appropriate word for this - alignment.
That is, you are requesting a duplication of a feature that is in the attributes dialog. As I wrote, this is a specific task of combining functions within a single interface. Considering that in addition to MRT, these can also be move/copy, sync, compare dialogs, where such a need cannot be excluded either, I still doubt the appearance of such an additive. Although it would be interesting to see the author's opinion.

P. S.: If the task was associated with names that have some kind of constant consistency, I would have written a script to run in one click.

[petermad]

2HalbschuhTouri

It is possible to combine multiple function in TC - for your task of setting the time stamp to the full hour and then multirename the files you can do the following:
Make these two commands in your usercmd.ini file (located in the same directory as your current wincmd.ini file - if not present, just make it)

Code: Select all

[em_set_whole_hour]
cmd=OPENATTRIBUTES= +thh.00.00

[em_mymrt]
cmd=em_set_whole_hour,cm_RestoreSelection,cm_MultiRenameFiles

Then you can use the command cm_mymrt in the Command line, in a Button in the buttonbar, as an Alias or in a Redefined hotkey, in the Directory hotlist, in the Start menu or in the Main menu.

The command will first automatically set the time stamp of the selected files to the whole hour, reselect the files and open the Multi Rename Tool.

It is also possible to make the Multi Rename tool automatically open a saved rename setting, rename the files and cloce again with the MULTIRENAME== <setting name> command

[HalbschuhTouri]

He, like you, did not give a methodology for how two or more types of operations should be performed simultaneously and even sequentially within the same interface, i.e. what I wrote above, but judging by the answers, you did not understand. And he did not explain why, at the same time, this dialog should leave the same name/title, unrelated to editing metadata.

You are quite right, I really have difficulties to relate to your compartmentalized approach of separated "types of operations" here. As from an NTFS-point-of-view the file-name is just another kind of "attribute", very much akin to time-stamps or the classical bit-type-attributes like "read only" or "system". So be it re-naming or re-setting one of the time-stamps - it all means re-writing the file-header on disk for crying out loud. So other than "move/copy" (as you've mentioned below) which is a totally different kind of ballgame re-naming as much as altering one of the other attributes or time-stamps pretty much represents the very same type of "operation" and I really can't see what's the big deal here that would forbid to perform them all together in one pass from a centralized location (the MRT) as in a "one-stop-shop-concept".

The use of the concept of "standardizing ... to". There is a more appropriate word for this - alignment.
That is, you are requesting a duplication of a feature that is in the attributes dialog.

I have no intention in dealing with pure semantics.

If the task was associated with names that have some kind of constant consistency, I would have written a script to run in one click.

Obviously a good idea for this particular problem. But standard users typically are not very much into programming or scripting and from my side this was only meant to serve as an example about how the GUI could easily provide the standard user with a more generalized and more versatile/powerful approach in terms of the OP's proposal.

[HalbschuhTouri]

It is possible to combine multiple function in TC - for your task of setting the time stamp to the full hour and then multirename the files you can do the following:
Make these two commands in your usercmd.ini file (located in the same directory as your current wincmd.ini file ...
It is also possible to make the Multi Rename tool automatically open a saved rename setting, rename the files and cloce again with the MULTIRENAME== <setting name> command

Many thanks for these most helpful hints about how to achieve an automated solution for this particular problem through scripting or even simple user-defined-commands. This may well help others - but again: from my side this was only meant as an example for the MRT-GUI to be enhanced in the future in terms of the OP's initial proposal to provide the standard-user with a "one-stop-shop-solution" within the GUI for all tasks altering the file-header for multiple files in a systematic fashion.

[petermad]

but again: from my side this was only meant as an example for the MRT-GUI to be enhanced in the future in terms of the OP's initial proposal to provide the standard-user with a "one-stop-shop-solution" within the GUI for all tasks altering the file-header for multiple files in a systematic fashion.

Well, to be more universal you could just use this command:

Code: Select all

[em_setattributesandmultirename]
cmd=cm_SetAttrib,cm_RestoreSelection,cm_MultiRenameFiles
menu=Set Attributes and Multi Rename selected files

It saves you the trouble of selecting the same files twice

[Galizza]

Please enhance the multi-rename tool so as to allow the user to change the date and time of a file, not just the name.

Support++

[Fla$her]

As from an NTFS-point-of-view the file-name is just another kind of "attribute", very much akin to time-stamps or the classical bit-type-attributes like "read only" or "system". So be it re-naming or re-setting one of the time-stamps - it all means re-writing the file-header on disk for crying out loud.

In MFT, streams (attributes, size, time, rights) and a pointer to sectors with data are stored in the mentioned header, the pointer to which, along with the file name, is already stored in the directory structure record. But this is about NTFS. It is not necessary to forget about other file systems with their own specifics. I think it is wrong to mix renaming and editing metadata, despite storing records in the same table/database (the $MFT file in the case of NTFS, although this does not apply to non-resident attributes). And the point is not that, but, again, how to work with what is requested, within the framework of a single interface. Whatever common features the names and attributes have, this does not negate the question of the methodology of work. You write a lot about the secondary, now tell us about the key.

[HalbschuhTouri]

Whatever common features the names and attributes have, this does not negate the question of the methodology of work. You write a lot about the secondary, now tell us about the key.

I'm not the one who introduced this proposal, I just happen to emphatically support it - nor would I be the one having to implement it and include it in some way into the current "framework of a single interface". But if you ask my advice how this could eventually be done - well, here you go.

The current interface provides headers above the filenames designating various relevant fields like "Old Name", "New Name", "Size" etc. with the possibility of sorting the field of files accordingly, one of them being "Date" which will include the time as well. Perhaps it would be an idea to include a simple checkbox "Change" into the "Date"-header-field that, if checked, would bring-up a pop-up-window duplicating/"borrowing" the time-setting-entries from the current "Change Attributes"-dialogue. It could be as simple as that. Or that checkbox could be added to each line of the file-entries to also enable individual date/time-changes. But I guess a group-wise change-option would be the preferred solution here. HTH.

[Fla$her]

would bring-up a pop-up-window duplicating/"borrowing" the time-setting-entries from the current "Change Attributes"-dialogue. It could be as simple as that.

It's illogical to duplicate this dialog, since it implies confirmation of edit before making changes to MRT, which contradicts the logic of the preview. And in fact, the mass edit will not differ in any way from what petermad proposed.

[HalbschuhTouri]

It's illogical to duplicate this dialog, since it implies confirmation of edit before making changes to MRT, which contradicts the logic of the preview. And in fact, the mass edit will not differ in any way from what petermad proposed.

"Borrowing" this dialog was of course meant in some suitably adapted way (without the direct confirmation-part that is). Instead of puristic and formalistic rejection of my proposal and with an ounce of phantasy you could have easily figured that out. The final confirmation would in this case of course be done (together with all the actual renaming) by the "Start"-button of the MRT.

As for the (already very constructive, as always) proposal by petermad: yes, in the end it would pretty much come to the same result. Although directly implementing the OP's proposal into the MRT would enable the average-user to easily make use of that added feature via GUI yet without the hassle of having to create multiple user-defined em_commands or - let alone - having to introduce scripting. It's all about convenience and broadened usability for non-experts and doesn't mean that it couldn't be done within the present TC-environment, albeit after having to introduce some advanced tweaking.

[Fla$her]

Instead of puristic and formalistic rejection of my proposal and with an ounce of phantasy you could have easily figured that out.

No. It's not about puristics, but how it should go in the logic of MRT and preview. All fields in the output of the results are visible, and you suggest making a hidden setting that will affect this preview without understanding whether the date is current or changed. Therefore, when I proposed the combobox, I proceeded from the logic of matching the current work.

[HalbschuhTouri]

...but how it should go in the logic of MRT and preview. All fields in the output of the results are visible, and you suggest making a hidden setting that will affect this preview without understanding whether the date is current or changed.

What is it about logic and preview? It couldn't be clearer for heaven's sake! Currently there is only one field showing the present time/date settings. Now if there were a checkbox "Change" in the header - and if it were checked - the date/time would change according to the popup-window which could be invoked for preview at any time and the changed/final date/time would also appear in the main date/time column for preview - and if that checkbox were not checked the current date/time would remain as indicated within the current implementation.

One could even argue that if the MRT doesn't (and shouldn't) allow for date/time-changes as a matter of principle - then why even further clutter-up the main preview window with a date/time-column in the first place if the latter is meant to be none of MRT's business?!

But if you need to have the current date/time visible at all times and if you prefer you could suggest another date/time column (current vs. new) in the main window. The drawback of course being that one more column in the main window would (in most cases) mean that horizontal scroll would become necessary to overlook all the columns at once or one would have to settle for a very small screen-font.

[petermad]

then why even further clutter-up the main preview window with a date/time-column in the first place

It is there so you can click on the header to sort by date/time - useful for example if you want to use the [C] modifier.

[HalbschuhTouri]

It is there so you can click on the header to sort by date/time - useful for example if you want to use the [C] modifier.

Thank you for that important hint. TBH I already knew that. But then again I'm not the one trying to argue that date/time should not be a matter of business for the MRT. Because - for instance - upon sorting the files-to-be-renamed by date/time it might turn out that something is wrong with their chronological order. Then why not allow the user to correct that situation directly from within the MRT? As correcting the chronological order of those (multiple) entries - as I see it - would again just be another kind of renaming-operation. One could perhaps even apply some (other) kind of counter for minutes and/or seconds as to differentiate those entries by the correct/desired chronological order.

[HalbschuhTouri]

All fields in the output of the results are visible, and you suggest making a hidden setting that will affect this preview without understanding whether the date is current or changed.

Sorry for having overlooked that plea raised for so long. But the answer is really simple. One column with date/time is already there, right? So after a possible change it should of course indicate the new/final date/time, And to indicate that this individual date/time has been altered by the MRT - simply print it in bold letters (or italic just in case you don't like bold here).