scanFile() does not return file id if scanned file matches cache entry 100% (same mtime)

[PVince81]

When scanFile() is called on a file, and that file is already in the cache, it will usually try and see if there are differences and whether the cache needs to be updated.

In case there are no differences (same mtime), scanFile() will return the found data.
However, that data will not contain the file id.

Found while debugging a race condition in a backport's unit test: #16369 (comment)

It is not clear yet whether this could happen on a productive instance, and if it happens whether it will cause strange errors.

[PVince81]

In that unit test we actually had the following situation:

1. The folder "files" did not exist on disk
2. The cache entry for "files" did exist in the cache
3. setupFS() / getUserFolder() would see that the folder does not exist, so it would create it.
4. The creation of the folder would trigger scanFile() as if it was a new folder
5. The scanFile() bug would not return the fileid and cause trouble with subsequent calls of calculateFolderSize()

[PVince81]

Looks like #10993 would cover this.

[PVince81]

#10993 was merged, closing