[Solved] Can I export journals with full timestamps since 1397a?

[Herkules97]

viewtopic.php?p=77151#p77151

So I finally have some space to make exports which I will then compress so I don't have to rely on the .db files for their data in case a new system will cause some of them to fail to load like what happened with this one. Maybe it requires the instance to have certain properties that none of my current ones do, Idk.

I still have pre-1.5x versions to export, but after that can I start exporting the old journals with their full data or is this only for that separate on-disk logging? I think Void mentioned it in a previous thread I made/was in, but it's not what I'm looking for. In-RAM is better for so many changes and it wouldn't apply retroactively anyway

As in the timestamps are saved as 2026-04-18 00:00:00.0000000 not 2026-04-18 00:00:00 or whatever a journal export currently does with 1390a and below. I think all other properties are exported fully, I don't remember nor did I probably ever compare. I saw the timestamps first probably and then skipped checking the rest.

[void]

The next alpha update will have a csv_filetime advanced setting to format to the desired resolution. (eg: second resolution or full resolution)

The default will always be second resolution because Excel doesn't auto format with milliseconds.



For now, set your log format to:

Code: Select all

$journal-id:,$change-id:,<FORMAT-FILETIME:$date:,"yyyy-MM-dd HH:mm:ss.SSSSSSS">,&quot:<SWITCH:$action:,1,"Folder Create",2,"Folder Delete",3,"Folder Rename",4,"Folder Move",5,"Folder Modify",6,"File Create",7,"File Delete",8,"File Rename",9,"File Move",10,"File Modify","">&quot:,"$filename:","$newfilename:",$size:

Export as TXT and rename to CSV.

[Herkules97]

The next alpha update will have a csv_filetime advanced setting to format to the desired resolution. (eg: second resolution or full resolution)

The default will always be second resolution because Excel doesn't auto format with milliseconds.

I don't use Excel and if I do read these it would probably be with Windows' Notepad.
Usually I use the journal entries when they're still in the db, but exports future-proof their access.

For now, set your log format to:

Code: Select all

$journal-id:,$change-id:,<FORMAT-FILETIME:$date:,"yyyy-MM-dd HH:mm:ss.SSSSSSS">,&quot:<SWITCH:$action:,1,"Folder Create",2,"Folder Delete",3,"Folder Rename",4,"Folder Move",5,"Folder Modify",6,"File Create",7,"File Delete",8,"File Rename",9,"File Move",10,"File Modify","">&quot:,"$filename:","$newfilename:",$size:

Export as TXT and rename to CSV.

As I understand reading the setting names, this is only for the on-disk logging which is not what I am doing so I guess the next update is what I'm looking for then. I did try it just to be sure and it fails as I think should be expected. I am stupid, I tried it with 1386a. After realising this, I tried 1405a and it works as expected. I will probably still wait for 1409a for the csv option.
Wouldn't on-disk logging hammer your HDDs or SSDs hard?

[void]

Wouldn't on-disk logging hammer your HDDs or SSDs hard?

No, not noticeably.
Writing to the log will only create two USN Journal events and the log is buffered by Everything and Windows.

You can leave journal logging disabled.
Changing the journal log format also applies to the txt export.

[void]

Everything 1.5.0.1409a adds an option to customize the CSV date/time format.

To set the CSV date/time format:

• In Everything 1.5, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  csv
• Select: csv_filetime
• Set the value to one of the following:
  • 0 = Local time (second resolution) (default)
  • 1 = local time (full resolution)
  • 2 = raw filetime
  • 3 = ISO8601 (UTC)
  • 4 = ISO8601 (with-timezone)
• Click OK.

csv_type must be set to 0 to use csv_filetime.
If csv_type is set to 1, the date/time format will always be raw filetime.

csv_type
csv_filetime



Everything 1.5.0.1409a also fixes an issue with ISO8601 (with-timezone) using the wrong daylight savings time.