I think this is NOT an Everything topic, but I stumbled across it while exploring the function Root:
This is, for me, an academic question.
Win7; a laptop with a single HDD split into a Boot partition and a data partition.
Root_01.png (24.89 KiB) Viewed 8243 times
In 1980 I was writing for mainframes in Paris; I did not buy this laptop until around 2005.
I am guessing that my Veracrypt encrypted data partition is dated 1980 because Veracrypt did not lodge a meaningful date back in 2005.
I suspect that 01/31/2023 was the most recent attempt by MS to upgrade my Win7 system.
Any other interpretations?
Thanks, Chris
Last edited by ChrisGreaves on Sat Feb 04, 2023 7:43 pm, edited 1 time in total.
1980-010-01 comes from FAT/FAT32/exFAT filesystem. It is their t=0 time.
The C: rootfolder time I didn't know, but it is an interesting question. After a short inspection:
A part of the NTFS filestystem is reserved for bookkeeping. This part is not visible for users.
Here the USN Journal and MFT (Master File Table) are living.
It is also home to a folder called "." The root: time comes form this folder. At least: it looks that way.
Your VeraCrypt volume might be a FAT/FAT32/exFAT rather than NTFS file system, in which case it may not maintain any meaningful volume modified time. All of my NTFS VeraCrypt volumes maintain an accurate Date Modified value.
raccoon wrote: ↑Tue Feb 07, 2023 9:23 pm
Your VeraCrypt volume might be a FAT/FAT32/exFAT rather than NTFS file system, in which case it may not maintain any meaningful volume modified time. All of my NTFS VeraCrypt volumes maintain an accurate Date Modified value.
Hi Raccoon.
My mistake. I am on an old Win7 laptop using TrueCrypt.
I poked around with ComputerManagement/DiskManagement and with Truecrypt, looking for the keyword FAT, then finally thought KISS and right-clicked on the drive in Windows Explorer:
Untitled.png (19.13 KiB) Viewed 7873 times
You are spot on!
It is a FAT volume created with Truecrypt.
raccoon wrote: ↑Wed Feb 08, 2023 2:36 pm
If you decide to create an NTFS *crypt volume, Everything will be able to index it faster and keep it updated more accurately through NTFS journalist.
OK NotNull; you've intrigued me.
I can re-create the *crypted volume any night after my nightly backup.
But why would Everything be able to index NTFS faster than FAT? I would not have expected the underlying structure to bring about any significant change in time?
Of course I still think in terms of the 100ms disk access times of the Good Old Days, and figure that 360,000 objects means "time to make a cup of tea", so whether it is one minute or two or three doesn't seem significant to me.
Roughly: Is it worth my time to remove then re-create, format, and reload my data partition?
If you were working with a tiny volume, I would say don't worry about it. It's up to you to decide if 1/3 of a terabyte is tiny or not.
Everything can index NTFS volumes far faster than FAT/FAT32/exFAT volumes because Everything grabs the NTFS $MFT file and reads it directly as a single document and builds its database from that. With any of the FAT volumes, Everything will have to make a multiple dozens, hundreds or millions of function calls to request discovery of each file, and each folder, and each file within each folder, and then each of the files and folders timestamps and attributes, etc, which can take many minutes.
On some of my FAT volumes, it takes 10 minutes to do all this, while my NTFS volumes with the same copy of data only take a few seconds to index.
Additionally, Everything has to try very hard to detect new files, changed files, renamed files, etc from FAT volumes, and a lot of this information simply cannot be monitored for passively and will require an active re-scan every so often. NTFS volumes capture all file changes into a journal of records that gets sent to Everything so that it's always kept perfectly up-to-date and in sync. No refreshing or re-scanning necessary.
NTFS also has better error catching and fixing than FAT, especially with power outages and such. FAT volumes get really annoyed when they're not powered down and dismounted correctly, throwing up a "Dirty Bit" that requires a ChkDisk scan before you're allowed to write any more data to the drive again.
Since you will never plug your TrueCrypt volume into a TV or Satellite Receiver or Playstation or Cellphone, there's no real practical reason to use FAT for that application.
raccoon wrote: ↑Wed Feb 08, 2023 7:53 pm... Everything grabs the NTFS $MFT file and reads it directly as a single document and ...
So this is akin to the "process in RAM rather than via HDD" argument. I get that.
... hundreds or millions of function calls to request discovery of each file,...
And this I understand from my days in Library Automation, especially circulation control systems.
On some of my FAT volumes, it takes 10 minutes to do all this, ...
This I can tolerate; it's what retirement is all about (grin!)
... there's no real practical reason to use FAT for that application.
You've convinced me! I will convert to NTFS on Saturday when it will be warm enough to walk to the shops! That will shave a bit off my downtime. (LATER) I did this This same evening, Wednesday.
Backed up my data partition, reformatted the encrypted partition, then RoboCopy'd data from the backup to the data partition on the HDD.
Thanks again!
Chris