"Allow files on this drive to have contents indexed in addtion to file properties" causes issues on network drive

[stulander]

Hi,

I have a shared folder in a drive and I've noticed toggling this option causes weird behaviour in Everything. Everything wasn't finding any files with it toggled off, at first.

I toggled it on. Everything started to show files on some PCs. Others, with the same drive added, showed nothing.

I tried reinstall Everything, on multiple PCs. Storing settings in Appdata rather than program files etc. Nothing fixed it. Followed various guides I found on this forum for similar issues.

Turning off indexing on the drive fixed it on all PCs.

Something weird is going on so I thought I'd mention it here. Not sure if it's a bug though. The drive in question was cloned from one VM (old file server) to a new VM (new file server) so that the complicated permissions structure was kept intact. (It's a simple way of doing it.) On the old VM indexing was on for the drive, on the new VM the indexing was by default off.

I'm guessing this is the cause for whatever reason.

[void]

Changing the "allow content indexing" attribute will generate a large amount of ReadDirectoryChanges events.

Consider exiting Everything before changing the "allow content indexing" attribute for an entire network drive.



Everything doesn't care about the "allow content indexing" attribute.
Changing this attribute would add the file/folder to your Everything index if it was missing from a recent scan.

Please try forcing a rescan from Tools -> Options -> Folders -> Select network folder -> Rescan Now.

[stulander]

Hi,

OK, I assumed it was the "allow context indexing" flag that affected it because everything seemed to start working again after I toggled it.

I've run into the issue again however on a different PC. Reinstalling (making sure the settings file is removed also) doesn't seem to fix it. The issue is only present on certain PCs.

The user can browse to the \\server\share, access files as normal. The file share is part of a DFS namespace (mentioning in case somehow relevant) although it's added to Everything as simply \\server\share. - Not using the DFS namespace.

Running "Rescan now" doesn't make any difference. Readding the folder, using the DFS name, and the FQDN also make no difference. On another PC I reinstalled everything and it seemed to start working.

I install everything with admin rights - I have to as this is a domain joined PC and the users don't have admin rights. I've tried storing settings in both appdata and C:\program files.

I am seeing this in the debug log:

2024-06-14 10:16:43.342: scanning \\hendrix.hydralan.local\company2...
2024-06-14 10:16:43.342: failed to open directory 2



I've attached the full debug log.

[void]

failed to open directory 2

Error 2 is path not found.

Please make sure sure the \\hendrix.hydralan.local\ resolves correctly.
Check if company2 is a valid and accessible share name for your current user account.

ipconfig /flushdns
ping hendrix.hydralan.local

[stulander]

This is why I'm convinced this is a bug.

Hendrix.hydralan.local resolves correctly. You can browse to the file share just fine. The server is definitely up. Only everything is not able to see it.

2024-06-14 11_41_07-Company2.png (13.04 KiB) Viewed 2786 times

I tried adding to everything:

\\hendrix\company2

\\hendrix.hydralan.local\company2

\\hydralan.local\fileserver\company (DFS namespace)

None of these work in everything. They all work when browsing with explorer. Oh - and I tried mapping a drive too. That also doesn't work.

[void]

Could you please capture a verbose debug log.

Check Tools -> Debug -> Verbose
Tools -> Debug -> Start Debug Logging.



The path is fine.
Everything sees the folder as a reparse point which is odd..
The scan then fails (verbose debug output will help here)

[stulander]

I let it run for a while and then stopped it.

[void]

Thanks for the log.

I'm looking into this issue.

[void]

There is no rescan attempts in this log.

Could you please try the following:

Check Tools -> Debug -> Verbose
Tools -> Debug -> Start Debug Logging.
Rescan your network share under the Index menu -> Rescan submenu -> click your network share.
Let Everything site for 1 minute while it attempts to rescan this folder.
Tools -> Debug -> Stop Debug Logging.
---This will open your Everything Debug Log.txt in Notepad.
Could you please upload this file here:
/bugreport

[stulander]

I've done that. Thanks

[void]

Thank you for the logs.

Everything 1.4 cannot read the attributes for this folder.
Error: Path not found.

It's possible this folder is a folder junction and Everything doesn't have read access to the target.



Does the issue occur in Everything 1.5?

Everything 1.5 reads folder attributes differently and doesn't require read-access.

[stulander]

Hi,

1.5a seems to work so I'll deploy that to my network.

On 1.4:
I tried adding \\server\share to everything and that also does not work. The share isn't a junction folder. But \\company.local\fileserver\share is a DFS namespace, which is a type of junction folder I think. If it were an issue with handling folder junctions then you'd think it'd work with \\server\share even if it doesn't work with \\company.local\fileserver\share.

I've attached a screenshot of the permissions applied on that share.

To reiterate, everything worked fine for years, it was only when I migrated the file server from server 2008r2 to server 2022 and introduced the DFS namespace that this issue happened. I don't know if removing the DFS namespace would have any impact, and I can't test it unfortunately.

Either way it looks like 1.5a solves the problem. It still doesn't make much sense that 1.4 wouldn't work though considering it's an identical copy from the old server with the same permissions - I backed up the entire disk drive with Veeam and attached it to a new VM.

Thanks