ntfs comp, fc miss some files without archive bit
Alexander Grigoriev
It finds the files that have at least one of the following bits set:
READONLY
NORMAL
COMPRESSED
ARCHIVE
HIDDEN
NORMAL bit is only set if neither of other bits is set, including also
ENCRYPTED and NOT_CONTENT_INDEXED.
The test2\dummy2.txt file has NOT_CONTEXT_INDEXED attribute, thus NORMAL bit
is not set.
This bit can be changed in Explorer, file properties, Advanced, For fast
searching, allow Indexing Service to index this file.
"Liviu" <lab...@hotmail.com> wrote in message
news:uJWyt036...@TK2MSFTNGP12.phx.gbl...
> This is a followup to my previous "xp comp, fc miss files without archive
> bit" post. Since then, I found out that only some, not all, files are
> affected - still, those affected consistently exhibit the problem. The
best
> I could do so far was to come up with a reproducible example (the .rar
> attached) which confirmed the issue on a few different machines, both XP
and
> 2K. The odd file in there is test\dummy2.txt - it is visible to "dir" and
> "copy" but not to "comp" or "fc" unless you turn its archive bit on. The
> rest of the .rar is just to verify that the problem does not lie with the
> directory itself, the filename or the actual contents.
>
> If you run XP (or 2K, maybe?) with an NTFS drive please try the
following...
> Expand the attached test2rar.rar preserving subdirectories and using
WinRar
> since the problem has to do with NTFS extended attributes or security in
> some eery way. Clear the archive attribute ("attrib -a") on all 4
extracted
> files. Open a command prompt in the parent of the directory where you
> un-rar'd, then try running..
> comp test test
> and
> comp test2 test2
> ..here, the first "comp" will simply ignore the test\dummy2.txt file. If I
> turn its archive bit on (attrib +a test\dummy2.txt) then "comp" will duly
> find it.
>
> This appears to be NTFS related (can't reproduce unless I check "save file
> security" in WinRar when creating the .rar file), however the command line
> "cacls" shows no difference between test\dummy2.txt which is affected, and
> test2\dummy2.txt which is not. Besides, there is the archive bit part
which
> has no bearing on security in my books.
>
> Beyond this, I don't have much of a clue yet. Only constants are that the
> "problem" files come from the XP machine which started this all, and were
> always created/copied on/to NTFS partitions. However, the "problem" -
> whatever it may be - appears to survive network copying, including 2K
> destinations, and even un/rar'ing as long as the NTFS info is preserved.
>
> Any insight into what is going on here will be GREATLY appreciated.
>
> Thanks,
> Liviu
>
> P.S. Sorry for posting attachments here, it's as tiny as I could make it.
>
>
>
>
Liviu
You are, of course, absolutely correct and turning on the "indexing" bit
fixes the issue. Many thanks, this has baffled me for a good couple of days.
Still, I respectfully submit that this is a bug in comp/fc and if it
affected popular commands like dir/copy it would have long been found and
fixed. I wonder what the most effective way to file a bug report would be.
"Alexander Grigoriev" <al...@earthlink.net> wrote in message
news:#lTF4i96...@TK2MSFTNGP10.phx.gbl...
Carl Daniel [VC++ MVP]
> Bingo !!
>
> You are, of course, absolutely correct and turning on the "indexing"
> bit fixes the issue. Many thanks, this has baffled me for a good
> couple of days.
>
> Still, I respectfully submit that this is a bug in comp/fc and if it
> affected popular commands like dir/copy it would have long been found
> and fixed. I wonder what the most effective way to file a bug report
> would be.
I agree. If this is something that's causing you problems in your day to
day work, you should consider calling Product Support Services and
requesting a QFE (hotfix).
I have reported this behavior through the MVP channels - you can also file a
bug report through product support services if you'd like.
-cd
Liviu
"Carl Daniel [VC++ MVP]" <cpda...@nospam.mvps.org> wrote in message
news:ePGe7e#6CHA...@TK2MSFTNGP10.phx.gbl...
Thank you for both the QFE advice and the MVP report.
Liviu