Filefind.get - archive bit issue.

[CALocklin]

I've been driven crazy a few times ever since A5v5 when using the FileFind.Get() function. Sometimes it just doesn't want to show me all the files that I know are there. I've known for a long time that the issue had to do with the "archive bit" in Windows but was using the function incorrectly and not able to get the complete list of all files - both those with and those without the archive bit turned on.

I finally figured it out and hopefully this video will help someone else with the same problem. (It is narrated so don't forget to turn up your audio!)

By the way, the Help info says (emphasis added): "The File_Attribute parameter is a numeric value specifying the type of file to find. You can find files that have one or more of the following attributes:" but apparently that is not true - they have to be found one at a time.

[Davidk]

Re: Filefind.get - archive bit issue.

I just know I'm going to be looking for this in 6 months... thanks.

[BigBoss1]

Re: Filefind.get - archive bit issue.

Thanks Cal, A really good job done.

[MikeC]

Re: Filefind.get - archive bit issue.

Cal,
Thanks....

It does look like you can use
FILE_FIND_NOT_DIRECTORY to find all files regardless of archive....makes a bit of sense that you cannot use FILE_FIND_ARCHIVE and FILE_FIND_NOT_ARCHIVE together as they negate each other.

FILE_FIND_READONLY+FILE_FIND_ARCHIVE also works.

I did not check out the other attributes yet.

[csda1]

Re: Filefind.get - archive bit issue.

Hi Cal and Mike,

This road was traveled down many years ago, and unfortuately, it has not changed.

There are 4 attributes associated with a file, Read-Only, Hidden, System and Archive bits. The value of 119 returns the most files, but not all values of attributes.

Here are some examples of codes (and these were the best of the 65636 possibilities). Each text file has the attributes of the file's name. However there are 3 settings that are not returnable which are

H-A -H-A.txt
HSA -HSA.txt
-SA --SA.txt

The ones above may not be "important for most Alpha applications, but it is still a limitation.

' There is no argument that returns the Read-only setting in the output,
' although it can be derived.

' This returns all 2 no read-only, no system, no hidden bits set
 ?filefind.get("C:\dirtest\*.txt",0,"-HSA N")
= ---- ----.txt
---A ---A.txt

' This returns all 4 no read-only and with archive bit set
?filefind.get("C:\dirtest\*.txt",32+4+2,"HSA N")
= --A ---A.txt
H-A -H-A.txt
HSA -HSA.txt
-SA --SA.txt

' This returns all 8 with Read only attribute
?filefind.get("C:\dirtest\*.txt",4+2+1,"HSA N")
= H-- RH--.txt
--- R---.txt
--A R--A.txt
H-A RH-A.txt
-S- R-S-.txt
HS- RHS-.txt
HSA RHSA.txt
-SA R-SA.txt

' This one get's all 13.  Unknown why 64 causes attributes ---- to happen
?filefind.get("C:\dirtest\*.txt",64+32+16+4+2+1,"HSA N")
= H-- RH--.txt
--- ----.txt
--A ---A.txt
H-A -H-A.txt
--- R---.txt
--A R--A.txt
H-A RH-A.txt
HSA -HSA.txt
-S- R-S-.txt
HS- RHS-.txt
HSA RHSA.txt
-SA --SA.txt
-SA R-SA.txt

[CALocklin]

Re: Filefind.get - archive bit issue.

It does look like you can use
FILE_FIND_NOT_DIRECTORY to find all files regardless of archive

Nice catch! That's definitely easier - and makes me feel silly for not discovering it in all these years. I guess I was stuck too deep in the rut of working out the archive issue. (Which became all the more of an issue with me when I was told that FILE_FIND_NORMAL would show everything with archive bit on or off - but it doesn't.)

....makes a bit of sense that you cannot use FILE_FIND_ARCHIVE and FILE_FIND_NOT_ARCHIVE together as they negate each other.

True - IF you think of it in the logic of the words. However, if you think of it in the same logic as adding numbers together where any combination will always total to a unique number (therefore you can "parse out" the individual numbers that were originally entered), then it should be possible. Plus, as noted above, the help text says, "The File_Attribute parameter is a numeric value specifying the type of file to find. You can find files that have one or more of the following attributes:" Then proceeds to list FILE_FIND_ARCHIVE and FILE_FIND_NOT_ARCHIVE along with all the rest.

And, thinking of it in terms of adding numbers together, if this works:
FILE_FIND_READONLY + FILE_FIND_ARCHIVE
shouldn't
FILE_FIND_ARCHIVE + FILE_FIND_NOT_ARCHIVE
work also? (Just a rhetorical question - no response required.)

And, this made me curious what the numbers were so I just ran the following in the Interactive Window. Any combination will indeed result in a unique number.
?FILE_FIND_NORMAL
= 0
?FILE_FIND_READONLY
= 1
?FILE_FIND_HIDDEN
= 2
?FILE_FIND_SYSTEM
= 4
?FILE_FIND_LABEL
= 8
?FILE_FIND_DIRECTORY
= 16
?FILE_FIND_ARCHIVE
= 32
?FILE_FIND_AND_FLAGS
= 128
?FILE_FIND_NOT_READONLY
= 256
?FILE_FIND_NOT_DIRECTORY
= 4096
?FILE_FIND_NOT_ARCHIVE
= 8192
?FILE_FIND_AND_NOT_FLAGS
= 32768

[csda1]

Re: Filefind.get - archive bit issue.

Hi Cal and Mike,

However there are 3 settings that are not returnable which are

H-A -H-A.txt
HSA -HSA.txt
-SA --SA.txt

Correction: The 3 not possible are the above without the archive bit, as in

H-- -H--.txt
HS- -HS-.txt
-S- --S-.txt

Returns for the examples Cal listed are

?filefind.get("C:\dirtest\*.txt",FILE_FIND_NOT_DIRECTORY,"HSA N")
= --- ----.txt
--A ---A.txt
--- R---.txt
--A R--A.txt

?filefind.get("C:\dirtest\*.txt",FILE_FIND_ARCHIVE,"HSA N")
= "--A ---A.txt"

?filefind.get("C:\dirtest\*.txt",FILE_FIND_NOT_ARCHIVE,"HSA N")
= --- ----.txt
--- R---.txt

?filefind.get("C:\dirtest\*.txt",FILE_FIND_READONLY + FILE_FIND_ARCHIVE,"HSA N")
= --A ---A.txt
--- R---.txt
--A R--A.txt

?filefind.get("C:\dirtest\*.txt",FILE_FIND_ARCHIVE + FILE_FIND_NOT_ARCHIVE,"HSA N")
= ""

[CALocklin]

Re: Filefind.get - archive bit issue.

[code]...
' This returns all 2 no read-only, no system, no hidden bits set
?filefind.get("C:\dirtest\*.txt",0,"-HSA N")
= ---- ----.txt
---A ---A.txt

Ira, if I'm reading that correctly, you are saying that the 0 attribute (file_find_normal) returns two files for you - the one WITH the archive bit set and the one WITHOUT the archive bit set.

If that is true, take another look at my video and explain why it doesn't work that way on my computer.

It also didn't work that way on my previous two computers and it didn't work that way on at least some of my customer's computers. That's why this has been such an issue for me. At one point I even had Marcel Kollenar write me a DLL that I could use to set the Archive attribute for all files in a folder. That was the only way I was able to get the "normal" attribute to actually list all the files.

Here are the results from today's test:

?filefind.get("E:\a5v9\*.mpx",FILE_FIND_NOT_DIRECTORY,"HSA N")
= --- test_archive_off.mpx
--A test_archive_on.mpx

?filefind.get("E:\a5v9\*.mpx",0,"HSA N")
= "--A test_archive_on.mpx"

?filefind.get("E:\a5v9\*.mpx",FILE_FIND_ARCHIVE,"HSA N")
= "--A test_archive_on.mpx"

?filefind.get("E:\a5v9\*.mpx",FILE_FIND_NOT_ARCHIVE,"HSA N")
= "--- test_archive_off.mpx"

[csda1]

Re: Filefind.get - archive bit issue.

Ira, if I'm reading that correctly, you are saying that the 0 attribute (file_find_normal) returns two files for you - the one WITH the archive bit set and the one WITHOUT the archive bit set.

If that is true, take another look at my video and explain why it doesn't work that way on my computer.

Unfortunately, I can't explain it. I've run tests on A5v8 and A5v9 (beta'd to ver 10). I tried another computer, an XP Home edition and got the same result. It also did not matter whether on a network drive or local.

I tried repeating the test on my XP Professional system with an NTFS formatted drive (I was doing it on a FAT32 drive), but the results came up the same for me for either drive.

On the off chance that something else in the directory was causing it to respond that way, I created a directory with only 2 files, 1 archived, 1 not.
It still comes up with both.

It also didn't work that way on my previous two computers and it didn't work that way on at least some of my customer's computers.

I can see why it would be confusing . The question is, why is it not consistent? I trust your methodology, and am also sure of mine, so it's got to be something else (maybe a virus checker, firewall or similar?) It certainly can't hurt concatonating the variations and eliminating the duplicates, but it would be good to know what's happening and why the inconsistency.

Did you try the setting with 119 or with setting the "64" value bit?

Have some code walk through the 65k combinations looking for the result with the greatest lines, or the greatest lines also containing the items desired. That's what I did.

Obviously 100% reliability and consistency is important in either case!

[CALocklin]

Re: Filefind.get - archive bit issue.

FOUND IT!

I had turned off the "indexing service" capability. I don't remember how - maybe a registry hack. I probably did it to speed things up just a little bit since I really didn't need that service for what I do.

Right below the "File is ready for archiving" checkbox is another checkbox for "For fast searching, allow Index Service to index this file". If that checkbox it unchecked, the FILE_FIND_NORMAL will not find it.

[csda1]

Re: Filefind.get - archive bit issue.

Hi Cal,

FOUND IT!

I had turned off the "indexing service" capability. I don't remember how - maybe a registry hack. I probably did it to speed things up just a little bit since I really didn't need that service for what I do.

Right below the "File is ready for archiving" checkbox is another checkbox for "For fast searching, allow Index Service to index this file". If that checkbox it unchecked, the FILE_FIND_NORMAL will not find it.

THAT'S GREAT!

Well at least that finds the setting that does it. Why? Who knows, but I sure wish it was more complete in finding all files and worked 100% as expected.

[MikeC]

Re: Filefind.get - archive bit issue.

Thanks Ira, Cal. Nice to have alternate ways and an explanation of what was happening--I too had turned off the indexing as I did not want to "confuse" the issue. LOL so much for that idea!!

[CALocklin]

Re: Filefind.get - archive bit issue.

FWIW - I did more testing and found that the File_get_date_time() function is another function that will not work if both the archive bit and the "Indexing Service" are turned off. I'm guessing there may be other file functions that are also affected by this.

In other words, make sure "Indexing Service" is not turned off on your system.

If you think it's turned off and want to turn it back on, go to the WINDOWS control panel, select Add/Remove Programs, select Add/Remove Windows Components, and make sure that "Indexing Service" is checked.

NOTE: In versions of Windows prior to XP, I don't believe there is an "Indexing Service". In that case, File_get_date_time() may not work at all if the archive bit is off - I don't currently have an older system so I can't check it. I obviously also can't test the older systems to see if using FILE_FIND_NOT_DIRECTORY in Filefind.get() will return the files with the archive bit off - maybe; but I did a lot of testing back when and I'm pretty sure I checked it back then with no luck.

So, if you have to work with an older OS, check it yourself to be sure.

[Carl Elmore]

Re: Filefind.get - archive bit issue.

In Windows 2000 you can control the indexing service by opening Windows Explorer and right clicking on the drive, choose properties and select the check box for the Indexing service.