File with mysterious attribute can't be seen

I am the developer of a commercial software application. One function
in this application writes some information to a text (.txt) file
which is placed in the same directory as the program (normally
underneath the Program Files directory). On Vista, it turns out that
this file is invisible to many programs, including Windows Explorer
and Notepad (although it is visible in the File Open dialog box in a
couple of other text editors that I tried). I do see it if I run a DIR
command at the command prompt. I then ran the ATTRIB command and saw
an attribute of "I" for this file, which I have never seen before. I
haven't been able to find any information on the meaning of this
attribute, and ATTRIB doesn't even support changing it, but my guess
is that it has something to do with the file's lack of visibility.
This problem does not occur on XP. I would like to find out what this
attribute means, why the file has it, and whether it is actually the
reason for the file not being seen.

Glenn

Glenn,
In general the c:\program files\ area is for installations of programs by a
'trusted installer' (i.e Microsoft Installer).
It should not be used to store user data. Having said that, many legacy
programs do just that. To keep them happy MS
sort of 'mirrors' the file at
C:\users\username\AppData\local\
You may find that your actual data file is there somewhere rather than
c:\program files

I recommend that, if you have control over the location where the data is
written, you place it somewhere more to MS liking such as the users
documents or public documents area. (You can do things MS way or the hard
way, the hard way is more interesting).

There is probably a MS white paper for developers that discusses where
application documents should be placed but I no longer do professional
development so have not kept up.

Michael


<galcott@nyc.rr.com> wrote in message
news:1180710533.563715.156640@q69g2000hsb.googlegroups.com...
>I am the developer of a commercial software application. One function
> in this application writes some information to a text (.txt) file
> which is placed in the same directory as the program (normally
> underneath the Program Files directory). On Vista, it turns out that
> this file is invisible to many programs, including Windows Explorer
> and Notepad (although it is visible in the File Open dialog box in a
> couple of other text editors that I tried). I do see it if I run a DIR
> command at the command prompt. I then ran the ATTRIB command and saw
> an attribute of "I" for this file, which I have never seen before. I
> haven't been able to find any information on the meaning of this
> attribute, and ATTRIB doesn't even support changing it, but my guess
> is that it has something to do with the file's lack of visibility.
> This problem does not occur on XP. I would like to find out what this
> attribute means, why the file has it, and whether it is actually the
> reason for the file not being seen.
>
> Glenn
>

I did change the application to write this file to the user documents
directory and that solved the problem. But I'm still mystified by what
happened here. The file really was in Program Files, not in any mirror
directory, but only some applications could see it and others
couldn't.

Glenn

Hello Glenn
Applications shouldn't care about seeing the file even though it's located
in the \program files folder. There may be issues with loading the file,
or reading the files depending on the security settings, but if a dir sees
the file, browsing to the file in an application should see the file.

As for the "I" attrib, it's for indexing:
C:\>attrib /?
Displays or changes file attributes.

ATTRIB [+R | -R] [+A | -A ] [+S | -S] [+H | -H] [+I | -I]
[drive:][path][filename] [/S [/D] [/L]]

+ Sets an attribute.
- Clears an attribute.
R Read-only file attribute.
A Archive file attribute.
S System file attribute.
H Hidden file attribute.
I Not content indexed file attribute.
[drive:][path][filename]
Specifies a file or files for attrib to process.
/S Processes matching files in the current folder
and all subfolders.
/D Processes folders as well.
/L Work on the attributes of the Symbolic Link versus
the target of the Symbolic Link


Thanks,
Darrell Gorter[MSFT]

This posting is provided "AS IS" with no warranties, and confers no rights
--------------------
|>From: galcott@nyc.rr.com
|>Newsgroups: microsoft.public.windows.vista.file_management
|>Subject: Re: File with mysterious attribute can't be seen
|>Date: Fri, 01 Jun 2007 11:16:07 -0700
|>Organization: http://groups.google.com
|>Lines: 9
|>Message-ID: <1180721767.214041.306520@p77g2000hsh.googlegroups.com>
|>References: <1180710533.563715.156640@q69g2000hsb.googlegroups.com>
|> <22208DF1-7AF2-4F74-A3C0-BC26BD620FC3@microsoft.com>
|>NNTP-Posting-Host: 72.229.178.153
|>Mime-Version: 1.0
|>Content-Type: text/plain; charset="iso-8859-1"
|>X-Trace: posting.google.com 1180721767 27493 127.0.0.1 (1 Jun 2007
18:16:07 GMT)
|>X-Complaints-To: groups-abuse@google.com
|>NNTP-Posting-Date: Fri, 1 Jun 2007 18:16:07 +0000 (UTC)
|>In-Reply-To: <22208DF1-7AF2-4F74-A3C0-BC26BD620FC3@microsoft.com>
|>User-Agent: G2/1.0
|>X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET
CLR 1.0.3705; .NET CLR 1.1.4322),gzip(gfe),gzip(gfe)
|>Complaints-To: groups-abuse@google.com
|>Injection-Info: p77g2000hsh.googlegroups.com; posting-host=72.229.178.153;
|> posting-account=-lv5ZA0AAABKemv5zflGYLCzQl5QX_zE
|>Path:
TK2MSFTNGHUB02.phx.gbl!TK2MSFTNGP01.phx.gbl!TK2MSFTFEEDS02.phx.gbl!news-out.
cwix.com!newsfeed.cwix.com!newscon02.news.prodigy.net!prodigy.net!border1.nn
tp.dca.giganews.com!nntp.giganews.com!postnews.google.com!p77g2000hsh.google
groups.com!not-for-mail
|>Xref: TK2MSFTNGHUB02.phx.gbl
microsoft.public.windows.vista.file_management:3878
|>X-Tomcat-NG: microsoft.public.windows.vista.file_management
|>
|>I did change the application to write this file to the user documents
|>directory and that solved the problem. But I'm still mystified by what
|>happened here. The file really was in Program Files, not in any mirror
|>directory, but only some applications could see it and others
|>couldn't.
|>
|>Glenn
|>
|>
|>