what matters here is the time between hard commits. If you do infrequent hard commits, then it is possible that files will be written to over that time. Those files are part-complete segment files, and are not yet referred to by the segments file, and thus are not really yet a part of the index. A commit will seal off those files, reference them from the segments file and from that point on they will not be touched. So you are right - a file may be added to before a commit, but I bet that even there - once the commit happens, those files are renamed to put them into the right place.
Again, my question is why do you want to know this timestamp? There is probably an easier way to achieve what you are trying to do. Upayavira On Thu, Sep 3, 2015, at 10:39 PM, Toke Eskildsen wrote: > Renee Sun <renee_...@mcafee.com> wrote: > > [core]/index is a folder holding index files. > > Agree so far. > > > But index files in that folder is not just being deleted or added, they are > > also being updated. > > So you say. That contradicts my understanding, as well as the first 10 > hits in Google for "lucene segment files immutable". The one file that is > updated is "segments.gen", which is tiny and keeps track of which > segments makes up the overall index. > > > on Linux file system, the folder's timestamp will only be updated if the > > files in it is being added or deleted, NOT updated. So if I check the index > > folder, it will not be accurately reflexing the last time the index files > > are updated. > > Just watch index/segments.gen. That is precise as it tracks when the > logical index was last updated, whereas segment files currently being > written are with later timestamps but not part of the index yet. > > - Toke Eskildsen
