About once a week I download a hundred config files one at a time from a web
archive that keeps changing so it's all done manually without wget and
without changing the names of the files to add a number one by one (which I
used to do manually but gave up).

To make it fast, I load a hundred tabs and I line up the SAVE button to the
same as the link so I can hold the control button down the whole time.

That way I can hold the control button down constantly and control left
click and then control SAVE (the control doesn't hurt the save) and then
control W to close that tab which moves to the next tab.

And so on until done.
It's fast.

Then I want to sort the results by the timestamp but I don't want to wait a
minute between saves and I gave up on manually renaming each file at the
time it is saved so they sort in order.

Is there an easy way to get a sort by greater granularity than seconds?

On 10-03-2022 08:01 wolfgang kern <nowhere@nospicedham.never.at> wrote:

> Is there an easy way to get a sort by greater granularity than seconds?

Should be but I just tried and there's no option in the dir command for it.
dir /t:c /o:d /b > oldestontopnewestonbottom.txt

wolfgang kern wrote:

> Is there an easy way to get a sort by greater granularity than seconds?

Are you saving to an NTFS or FAT file system? The latter only has a 2 second
timestamp resolution.

On 3/10/2022 2:51 AM, Andy Burns wrote:
> wolfgang kern wrote:
>
>> Is there an easy way to get a sort by greater granularity than seconds?
>
> Are you saving to an NTFS or FAT file system?  The latter only has a 2 second timestamp resolution.
>

NTFS has 64-bit timestamps, with 100ns granularity. Something like that.

Still, I see no reason for an OS sort routine to use anything other than seconds.

Even though in the example which follows, you can see the timestamp numbers have
"lots of bits" to work with :-)

Maybe preparing a listing with Everything.exe from voidtools.com would work or so.
Tossing "every_c.txt" into Excel and sorting might work.

Everything.exe -create-filelist every_c.txt "C:"

Filename, Size, Date Modified, Date Created, Attributes
"C:\$Recycle.Bin", 0, 131078764559534022, 130216593913750702, 22
"C:\$Recycle.Bin\S-1-5-18", 0, 130537892887281678, 130537892886969158, 22

******* filetime.c ******* /* Note - not designed for public consumption, ui needs work/help */
/* Hack and make it better */

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include <Windows.h>
#include <WinBase.h>

int main(int argc, char *argv[])
{ FILETIME timein;
SYSTEMTIME stUTC, stLocal;
DWORD dwRet;

long long int arrgh;
int conv1;

/* typedef struct _FILETIME { = 131679807063691748;
DWORD dwLowDateTime; 1D3D216 0x3C1F91E4
DWORD dwHighDateTime;

timein.dwLowDateTime = 0x3C1F91E4;
timein.dwHighDateTime = 0x01D3D216; */

if (argc != 2) goto later;
if ( (conv1 = sscanf(argv[1], "%I64d", &arrgh)) == 0) goto later;
timein.dwLowDateTime = (unsigned int) 0xFFFFFFFF & arrgh;
timein.dwHighDateTime = (unsigned int) 0xFFFFFFFF & (arrgh >> 32);

printf("%X %X\n", timein.dwHighDateTime, timein.dwLowDateTime);

FileTimeToSystemTime(&timein, &stUTC);

SystemTimeToTzSpecificLocalTime(NULL, &stUTC, &stLocal);

printf("%02d/%02d/%d %02d:%02d:%02d.%03d\n",
stLocal.wMonth, stLocal.wDay, stLocal.wYear,
stLocal.wHour, stLocal.wMinute,
stLocal.wSecond, stLocal.wMilliseconds);

later: return 0;
}

******* Usage of filetime.c *******

S:\> filetime.exe 131679807063691748
1D3D216 3C1F91E4
04/12/2018 00:25:06.369

S:\>

*******

Paul

Paul wrote:

> Even though in the example which follows, you can see the timestamp numbers have
> "lots of bits" to work with

fairly easy to get it to milliseconds with powershell

get-childItem C:\ | forEach { echo $_.name,
$_.lastWriteTimeUtc.toString("yyyy-MM-dd HH:mm:ss.ffff") }

Paul wrote:

> Andy Burns wrote:
>
>> wolfgang kern wrote:
>>
>>> Is there an easy way to get a sort by greater granularity than seconds?
>>
>> Are you saving to an NTFS or FAT file system?  The latter only has a 2 second
>> timestamp resolution.
>
> NTFS has 64-bit timestamps, with 100ns granularity. Something like that.

Yes, I know NTFS doesn't have a problem, I doubt the O/P has any reason to use
FAT, but worth asking ...

In article <t0bnta$3mm$1@gioia.aioe.org>, nowhere@nospicedham.never.at says...
>
> About once a week I download a hundred config files one at a time from a web
> archive that keeps changing so it's all done manually without wget and
> without changing the names of the files to add a number one by one (which I
> used to do manually but gave up).
>
> To make it fast, I load a hundred tabs and I line up the SAVE button to the
> same as the link so I can hold the control button down the whole time.
>
> That way I can hold the control button down constantly and control left
> click and then control SAVE (the control doesn't hurt the save) and then
> control W to close that tab which moves to the next tab.
>
> And so on until done.
> It's fast.
>
> Then I want to sort the results by the timestamp but I don't want to wait a
> minute between saves and I gave up on manually renaming each file at the
> time it is saved so they sort in order.
>
> Is there an easy way to get a sort by greater granularity than seconds?

I don't know enough about the situation to give any sort of full answer, but it
might be worth considering that if you download a second (third, etc) copy of
an identically-named file, the Windows filesystem adds distinguishing numeric
suffixes automatically. So Menu.pdf becomes Menu(1).pdf the second time, and
so on. I wonder if there's a solution arising from that?

--

Phil, London

On 10.03.2022 12:50, Andy Burns wrote:

>> Even though in the example which follows, you can see the timestamp numbers have
>> "lots of bits" to work with
>
> fairly easy to get it to milliseconds with powershell
>
> get-childItem C:\ | forEach { echo $_.name,
> $_.lastWriteTimeUtc.toString("yyyy-MM-dd HH:mm:ss.ffff") }

Right clicking on the drive in Windows file explorer and selecting
"Properties" says all my hard disk drives are NTFS as expected.

The only time I ever used the powershell was to clean up programs after an
initial Windows 10 setup and even then I only cut & pasted the instructions.

Run => powershell [control][shift][enter]
cd c:\filespec\
get-childItem | forEach { echo $_.name,$_.lastWriteTimeUtc.toString("yyyy-MM-dd HH:mm:ss.ffff") }

filename.ext
2022-03-10 15:03:33.9315
filename.ext
2022-03-10 15:04:15.8065
filename.ext
2022-03-10 15:04:09.9675
filename.ext
2022-03-10 15:04:42.1215
filename.ext
2022-03-10 15:04:24.1255
filename.ext
2022-03-10 15:04:37.7755
filename.ext
2022-03-10 15:02:40.6105
filename.ext
2022-03-10 15:03:11.5205
filename.ext
2022-03-10 15:02:25.1355
filename.ext
2022-03-10 15:03:36.8565
filename.ext
2022-03-10 15:03:02.8575
filename.ext
2022-03-10 15:01:53.5265
filename.ext
2022-03-10 15:02:33.1195
filename.ext

All I need to do now is look up how to condense to one line for each file
with the date in front so that I can sort in an editor with the oldest on
top and newest on bottom.

Thank you for explaining that Windows NTFS has a deeper date granularity.

On 10.03.2022 12:45, Philip Herlihy wrote:

> I don't know enough about the situation to give any sort of full answer, but it
> might be worth considering that if you download a second (third, etc) copy of
> an identically-named file, the Windows filesystem adds distinguishing numeric
> suffixes automatically. So Menu.pdf becomes Menu(1).pdf the second time, and
> so on. I wonder if there's a solution arising from that?

Given there are literally about a hundred tabs, as you foresaw, I sometimes
click twice on the same file and as you said, sometimes the same file names
are already in the folder.

The simple solution I've been using to work around those inevitable filename
clashes is to initially save the files to a separate temporary folder which
eliminates clashes to previous downloads.

And then I delete any filename(1).ext files that resulted from a clash
either due to the same file twice or to accidentally hitting a save twice
without closing it in the hundred tabs (which happens).

Then I cut and paste the files in the temporary folder to the archive folder
and I let Windows 10 skip moving any files that are already there. And then
I delete the temporary folder and any files remaining that had clashed.

Thank you for warning me about those two problems.
Sounds like you've been where I am now.

All I need to do now is learn how to sort them with the oldest files on top
because the filelist ends up going into a shell script that expects a long
list of filespecs in LIFO order.

wolfgang kern wrote:

> All I need to do now is look up how to condense to one line for each file with
> the date in front so that I can sort in an editor with the oldest on top and
> newest on bottom.

You can include the sort within powershell, then there's various formatting
options, but for ease try this, I've removed they punctuation from the datetime,
but you can put the back in if you prefer them

get-childItem | sort-object -prop lastWriteTimeUtc | forEach { "{0} {1}" -f
$_.lastWriteTimeUtc.toString("yyyyMMddHHmmssffff"), $_.name }

On 10.03.2022 08:32, Andy Burns wrote:

>> All I need to do now is look up how to condense to one line for each file with
>> the date in front so that I can sort in an editor with the oldest on top and
>> newest on bottom.
>
> You can include the sort within powershell, then there's various formatting
> options, but for ease try this, I've removed they punctuation from the datetime,
> but you can put the back in if you prefer them
>
> get-childItem | sort-object -prop lastWriteTimeUtc | forEach { "{0} {1}" -f
> $_.lastWriteTimeUtc.toString("yyyyMMddHHmmssffff"), $_.name }

Thank you for the powershell command to sort by oldest first.
The script I paste the list of files into requires a LIFO list order.
I was going to do it inside of vim but your mod saves me a step.

Here are the timed results from the latest set of downloads with the
filename obscured for the purpose of this post, but with actual datestamps.

get-childItem | sort-object -prop lastWriteTimeUtc | forEach { "{0} {1}" -f $_.lastWriteTimeUtc.toString("yyyyMMddHHmmssffff"), $_.name }
202203101501163475 filename.ext
202203101501218025 filename.ext
202203101501264255 filename.ext
202203101501294065 filename.ext
202203101501321265 filename.ext
202203101501349255 filename.ext
202203101501375585 filename.ext
202203101501398745 filename.ext
202203101501427725 filename.ext
202203101501453915 filename.ext
202203101501480805 filename.ext
202203101501506825 filename.ext
202203101501535265 filename.ext
202203101501563795 filename.ext
202203101501591255 filename.ext
202203101502017355 filename.ext
202203101502044045 filename.ext
202203101502070475 filename.ext
202203101502096055 filename.ext
202203101502141605 filename.ext
202203101502166215 filename.ext
202203101502192405 filename.ext
202203101502224455 filename.ext
202203101502251355 filename.ext
202203101502280175 filename.ext
202203101502306485 filename.ext
202203101502331195 filename.ext
202203101502355765 filename.ext
202203101502381455 filename.ext
202203101502406105 filename.ext
202203101502432355 filename.ext
202203101502457555 filename.ext
202203101502480195 filename.ext
202203101502505155 filename.ext
202203101502528595 filename.ext
202203101502554065 filename.ext
202203101502579135 filename.ext
202203101503004375 filename.ext
202203101503028575 filename.ext
202203101503056315 filename.ext
202203101503089995 filename.ext
202203101503115205 filename.ext
202203101503139765 filename.ext
202203101503172895 filename.ext
202203101503199125 filename.ext
202203101503226545 filename.ext
202203101503252335 filename.ext
202203101503281585 filename.ext
202203101503312035 filename.ext
202203101503339315 filename.ext
202203101503368565 filename.ext
202203101503397315 filename.ext
202203101503423775 filename.ext
202203101503449885 filename.ext
202203101503475555 filename.ext
202203101503499805 filename.ext
202203101503524785 filename.ext
202203101503551275 filename.ext
202203101503574815 filename.ext
202203101504007015 filename.ext
202203101504033835 filename.ext
202203101504066995 filename.ext
202203101504099675 filename.ext
202203101504158065 filename.ext
202203101504191135 filename.ext
202203101504216815 filename.ext
202203101504241255 filename.ext
202203101504265335 filename.ext
202203101504289435 filename.ext
202203101504311535 filename.ext
202203101504333775 filename.ext
202203101504356005 filename.ext
202203101504377755 filename.ext
202203101504400045 filename.ext
202203101504421215 filename.ext
202203101504443845 filename.ext
202203101504465735 filename.ext
202203101504487745 filename.ext
202203101504510205 filename.ext
202203101504533025 filename.ext
202203101504555905 filename.ext
202203101504577095 filename.ext
202203101504599955 filename.ext
202203101505021865 filename.ext
202203101505044015 filename.ext
202203101505067035 filename.ext
202203101505090885 filename.ext

This hint is great to save in the batch file snippets folder!

wolfgang kern wrote:

> get-childItem | sort-object -prop lastWriteTimeUtc | forEach { "{0} {1}" -f
> $_.lastWriteTimeUtc.toString("yyyyMMddHHmmssffff"), $_.name }

you might want to add
-file
after the get-childItem to exclude folders

and maybe use
'{0} "{1}"'
as the format string to wrap double quotes around filenames in-case they include
spaces

wolfgang kern <nowhere@nospicedham.never.at> wrote:
> On 10.03.2022 12:45, Philip Herlihy wrote:
>
>> I don't know enough about the situation to give any sort of full answer, but it
>> might be worth considering that if you download a second (third, etc) copy of
>> an identically-named file, the Windows filesystem adds distinguishing numeric
>> suffixes automatically. So Menu.pdf becomes Menu(1).pdf the second time, and
>> so on. I wonder if there's a solution arising from that?
>
> Given there are literally about a hundred tabs, as you foresaw, I sometimes
> click twice on the same file and as you said, sometimes the same file names
> are already in the folder.
>
> The simple solution I've been using to work around those inevitable filename
> clashes is to initially save the files to a separate temporary folder which
> eliminates clashes to previous downloads.
>
> And then I delete any filename(1).ext files that resulted from a clash
> either due to the same file twice or to accidentally hitting a save twice
> without closing it in the hundred tabs (which happens).
>
> Then I cut and paste the files in the temporary folder to the archive folder
> and I let Windows 10 skip moving any files that are already there. And then
> I delete the temporary folder and any files remaining that had clashed.
>
> Thank you for warning me about those two problems.
> Sounds like you've been where I am now.
>
> All I need to do now is learn how to sort them with the oldest files on top
> because the filelist ends up going into a shell script that expects a long
> list of filespecs in LIFO order.

Honestly, given the room for error I would write a wrapper script around
wget or curl and solve the problem once and for all. As you're doing this
every week the time spent on the script will be saved in the long run.
https://xkcd.com/1205/