cygwin makes shared folders on vista

[jxt]

If I do a mkdir in a bash shell, it creates a folder that vista thinks is shared. Doesn't happen in the normal vista cmd shell. Doesn't happen on XP. And turning off sharing in vista takes forever (minutes).

Worse, if I untar a tgz file, in cmd or bash, it creates a vista shared folder. chmod -R doesn't help, and unsharing in vista again takes forever and doesn't even unshare all the sub folders and files.

Has anyone else seen this behavior? Any idea how to fix it? Could my cygwin installation be bad?

Thanks.

[nmehta]

jxt wrote:

If I do a mkdir in a bash shell, it creates a folder that vista thinks is shared. Doesn't happen in the normal vista cmd shell. Doesn't happen on XP. And turning off sharing in vista takes forever (minutes).

Worse, if I untar a tgz file, in cmd or bash, it creates a vista shared folder. chmod -R doesn't help, and unsharing in vista again takes forever and doesn't even unshare all the sub folders and files.

Has anyone else seen this behavior? Any idea how to fix it? Could my cygwin installation be bad?

Thanks.

I see the exact same behavior on every Cygwin/Vista installation I've done.  This also happens when you create a file in Cygwin (just touch a file to test it).  I can only presume that there is something fundamentally wrong about how Cygwin creates ACLs (Access Control Lists, the Windows version of permissions) when you create files or folders on Vista.

Comparing a file touched in Cygwin vs a file created in Vista, the ACLs look different (Cygwin has 'Everyone' while Vista has 'SYSTEM', and Cygwin has 'Users' while Vista has the actual group you are in, or in this case 'Administrators').  If you remove the permissions on 'Users' the icon will go away.  It looks like the fundamental problem is that Cygwin is not creating files/folders with the correct group permissions for Vista?

Wondering if any of the devs have a comment on this (Or have they seen this effect in Vista?  Can't miss it if you've installed it).

[jxt]

nmehta wrote:

I see the exact same behavior on every Cygwin/Vista installation I've done.  This also happens when you create a file in Cygwin (just touch a file to test it).  I can only presume that there is something fundamentally wrong about how Cygwin creates ACLs (Access Control Lists, the Windows version of permissions) when you create files or folders on Vista.

Wondering if any of the devs have a comment on this (Or have they seen this effect in Vista?  Can't miss it if you've installed it).

Wow, I had given up on getting a reply, since it's been about six weeks since my
original message. Thanks for at least confirming that I'm not crazy. However, as
this is the *users* mailing list, I'm wondering if developers hang out here regularly.
Is there somewhere else to post that would get more developer attention?

jxt wrote:
> However, as this is the *users* mailing list, I'm wondering if
> developers hang out here regularly.

They do.

> Is there somewhere else to post that would get more developer attention?

Nope. This is the right place.

Well, maybe there is... I'm sure if you called one of them, for example,
you would get more attention, but not likely the kind of attention you
want :-).

--
Matthew
Microsoft: driving people fscking insane...


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

[Brian Dessent]

nmehta wrote:

> Comparing a file touched in Cygwin vs a file created in Vista, the ACLs look
> different (Cygwin has 'Everyone' while Vista has 'SYSTEM', and Cygwin has
> 'Users' while Vista has the actual group you are in, or in this case
> 'Administrators').  If you remove the permissions on 'Users' the icon will
> go away.  It looks like the fundamental problem is that Cygwin is not
> creating files/folders with the correct group permissions for Vista?

You're simply seeing how ACLs work with native apps -- they inherit the
permissions in the ACL of the containing directory.

$ uname -s
CYGWIN_NT-6.0

$ ( mkdir /c/cygwin_created_dir; cd /c/cygwin_created_dir; touch a; cmd
/c "echo foo >b"; ls -ld . a b; getfacl . a b )
drwxr-xr-x+ 2 brian None 0 Oct 12 13:43 .
-rw-r--r--  1 brian None 0 Oct 12 13:43 a
-rwxr-xr-x  1 brian None 6 Oct 12 13:43 b
# file: .
# owner: brian
# group: None
user::rwx
group::r-x
mask:rwx
other:r-x
default:user::rwx
default:group::r-x
default:other:r-x

# file: a
# owner: brian
# group: None
user::rw-
group::r--
mask:rwx
other:r--

# file: b
# owner: brian
# group: None
user::rwx
group::r-x
mask:rwx
other:r-x

$ ( cmd /c 'mkdir c:\native_created_dir'; cd /c/native_created_dir;
touch a; cmd /c "echo foo >b"; ls -ld . a b; getfacl . a b )
d---------+ 2 brian None 0 Oct 12 13:44 .
-rw-r--r--  1 brian None 0 Oct 12 13:44 a
----------+ 1 brian None 6 Oct 12 13:44 b
# file: .
# owner: brian
# group: None
user::---
group::---
group:SYSTEM:rwx
group:Administrators:rwx
group:Users:r-x
mask:rwx
other:---
default:group:SYSTEM:rwx
default:group:Administrators:rwx
default:group:Users:r-x
default:mask:rwx

# file: a
# owner: brian
# group: None
user::rw-
group::r--
mask:rwx
other:r--

# file: b
# owner: brian
# group: None
user::---
group::---
group:SYSTEM:rwx
group:Administrators:rwx
group:Users:r-x
mask:rwx
other:---

So, I don't see what's wrong here.  The files created by the native app
took the defaults from the dir, so if something is not happening the way
you like make sure the dir is created with the right DACL first.  Or if
you'd rather have Cygwin behave like the native programs then set
CYGWIN=nontsec.

jxt wrote:

> Wow, I had given up on getting a reply, since it's been about six weeks
> since my
> original message. Thanks for at least confirming that I'm not crazy.
> However, as
> this is the *users* mailing list, I'm wondering if developers hang out here
> regularly.
> Is there somewhere else to post that would get more developer attention?

Now you're just being ridiculous.  Nowhere is the mailing list described
as a users mailing list, unless somebody at Nabble has messed up.  The
description on cygwin.com is quite clear that this is the right list for
nearly all Cygwin related topics.  And besides, it is trivially easy to
show that all the Cygwin developers follow this list closely because
there are hundreds if not thousands of messages by them in the archives.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

[nmehta]

Brian Dessent wrote:

So, I don't see what's wrong here.  The files created by the native app
took the defaults from the dir, so if something is not happening the way
you like make sure the dir is created with the right DACL first.  Or if
you'd rather have Cygwin behave like the native programs then set
CYGWIN=nontsec.

Thank you for pointing out getfacl, I didn't know that existed.  You are right in that the ACLs from getfacl match up correctly.  Also, if you create a directory in Cygwin on /c like you did it does not show up as shared.  If you create a directory in your Vista home directory (/c/Users/<username>/) on the other hand it shows up as shared.  I thought there was something about the /c/Users/<username> directory where child folders inherit the parent's settings as you alluded to; however, the /c/Users/<username> dir is not shared by default.  Is setting a folder to be shared separate from the ACLs?  If I create a folder in Vista and set it to shared/not shared getfacl returns the same thing.  Do you have any more insight about this?

I can also say that CYGWIN=notntsec does fix this behavior (created folders are no longer shared).  I have searched for information about this setting but haven't yet found a good explanation.  Can you shed some light on what this env variable does, and what are the consequences of setting it (or point me to a post/resource that can explain it?)

Brian Dessent wrote:

Now you're just being ridiculous.  Nowhere is the mailing list described
as a users mailing list, unless somebody at Nabble has messed up.  The
description on cygwin.com is quite clear that this is the right list for
nearly all Cygwin related topics.  And besides, it is trivially easy to
show that all the Cygwin developers follow this list closely because
there are hundreds if not thousands of messages by them in the archives.

Lighten up.  The guy got no responses for six weeks with maybe his first post to the list.  Additionally, the forum on Nabble is entitled "Cygwin Users".  A simple 'No, the devs do in fact read this list' would suffice.

[Larry Hall (Cygwin)]

nmehta wrote:
>


<snip>


> I can also say that CYGWIN=notntsec does fix this behavior (created folders
> are no longer shared).  I have searched for information about this setting
> but haven't yet found a good explanation.  Can you shed some light on what
> this env variable does, and what are the consequences of setting it (or
> point me to a post/resource that can explain it?)


<http://cygwin.com/cygwin-ug-net/using-cygwinenv.html>

> Brian Dessent wrote:
>> Now you're just being ridiculous.  Nowhere is the mailing list described
>> as a users mailing list, unless somebody at Nabble has messed up.  The
>> description on cygwin.com is quite clear that this is the right list for
>> nearly all Cygwin related topics.  And besides, it is trivially easy to
>> show that all the Cygwin developers follow this list closely because
>> there are hundreds if not thousands of messages by them in the archives.
>>
>
> Lighten up.  The guy got no responses for six weeks with maybe his first
> post to the list.  Additionally, the forum on Nabble is entitled "Cygwin
> Users".  A simple 'No, the devs do in fact read this list' would suffice.

Perhaps.  But it's not a Nabble requirement that the Cygwin web site be
avoided.  And since Nabble really has nothing whatsoever to do with Cygwin,
using it as a source of data for anything Cygwin isn't a good idea.  If the
OP needed to know if he was posting to the right forum, a trip to the Cygwin
site would seem to be in order.  Also, it seems it's time to once again note
that this isn't a paid support service.  One isn't guaranteed a response
in any particular time-frame or even ever.  The volunteers here answer
questions as their time and knowledge permit.  Usually, if no one answers
a particular thread, it's because no one has a good response, at least
at that time.  But the problem reports are always read by everyone on this
list, including the Cygwin developers.


--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      [phone] - RFK Office
216 Dalton Rd.                          [phone] - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

[nmehta]

Larry Hall (Cygwin) wrote:

nmehta wrote:
>


<snip>


> I can also say that CYGWIN=notntsec does fix this behavior (created folders
> are no longer shared).  I have searched for information about this setting
> but haven't yet found a good explanation.  Can you shed some light on what
> this env variable does, and what are the consequences of setting it (or
> point me to a post/resource that can explain it?)


<http://cygwin.com/cygwin-ug-net/using-cygwinenv.html>


> Brian Dessent wrote:
>> Now you're just being ridiculous.  Nowhere is the mailing list described
>> as a users mailing list, unless somebody at Nabble has messed up.  The
>> description on cygwin.com is quite clear that this is the right list for
>> nearly all Cygwin related topics.  And besides, it is trivially easy to
>> show that all the Cygwin developers follow this list closely because
>> there are hundreds if not thousands of messages by them in the archives.
>>
>
> Lighten up.  The guy got no responses for six weeks with maybe his first
> post to the list.  Additionally, the forum on Nabble is entitled "Cygwin
> Users".  A simple 'No, the devs do in fact read this list' would suffice.


Perhaps.  But it's not a Nabble requirement that the Cygwin web site be
avoided.  And since Nabble really has nothing whatsoever to do with Cygwin,
using it as a source of data for anything Cygwin isn't a good idea.  If the
OP needed to know if he was posting to the right forum, a trip to the Cygwin
site would seem to be in order.  Also, it seems it's time to once again note
that this isn't a paid support service.  One isn't guaranteed a response
in any particular time-frame or even ever.  The volunteers here answer
questions as their time and knowledge permit.  Usually, if no one answers
a particular thread, it's because no one has a good response, at least
at that time.  But the problem reports are always read by everyone on this
list, including the Cygwin developers.

You make some very good points.  I mainly took exception to the tone of the response.  It's not hard to be civil and (IMO) there's no reason to call that particular post "ridiculous".  There were however problems with it, and I think your response points those problems out in an educational manner.

[Christopher Faylor-8]

On Sun, Oct 14, 2007 at 12:26:14AM -0700, nmehta wrote:
>You make some very good points.  I mainly took exception to the tone of
>the response.  It's not hard to be civil and (IMO) there's no reason to
>call that particular post "ridiculous".  There were however problems
>with it, and I think your response points those problems out in an
>educational manner.
>--
>View this message in context: http://www.nabble.com/cygwin-makes-shared-folders-on-vista-tf4360979.html#a13196709
>Sent from the Cygwin Users mailing list archive at Nabble.com.

It's harder than you might think after fielding hundreds of these types
of questions, especially when such resources as google exist.  Add to
that the annoying obfuscation provided by nabble, and it is sometimes
hard to be patient with misconceptions.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

[jxt]

Christopher Faylor-8 wrote:

It's harder than you might think after fielding hundreds of these types
of questions, especially when such resources as google exist.  Add to
that the annoying obfuscation provided by nabble, and it is sometimes
hard to be patient with misconceptions.

Just to bring some closure to this side-discussion, I'm the original poster,
and that *was* my first ever post to this list. I am using Nabble, for this list
and numerous others. I find Nabble to be quite a good way to keep up with
various lists. I *believed* that this was a user's list, possibly because it
was listed that way in Nabble. However, checking today, I see that this
list is now called "Cygwin list". Either it has been changed since last week
or I was just confused last week with the numerous other Nabble lists that
I frequent. Sorry for that error.

Now, as to the original question about shared folders being created by
cygwin on vista, it appears that a solution is in hand, though I have not
yet tested it in my envrionment. Indeed I had tried some googling, and
even searching the archives of this list (using Nabble) before the post,
but I guess I wasn't using to right search strings. I've had so many fights
with vista, absolutely nothing surprises me when it behaves strangely.

Might I suggest a link on the home page entitled something like "Cygwin
on Vista" with tips on how to best survive vista. Meanwhile, MANY THANKS
to all the developers of cygwin. I simply could not function on windoze
without cygwin. You provide an invaluable service.

[DePriest, Jason R.]

On 10/15/07, jxt <> wrote:
- - - - - cut - - - - -
> Now, as to the original question about shared folders being created by
> cygwin on vista, it appears that a solution is in hand, though I have not
> yet tested it in my envrionment. Indeed I had tried some googling, and
> even searching the archives of this list (using Nabble) before the post,
> but I guess I wasn't using to right search strings. I've had so many fights
> with vista, absolutely nothing surprises me when it behaves strangely.
- - - - cut - - - - - -

What was the solution?  CYGWIN=nontsec?  That's an odd solution
because I thought that would mess up how cygwin manages permissions.

From the User's Guide
"(no)ntsec - if set, use the NT security model to set UNIX-like
permissions on files and processes."

That implies that if this is NOT set that cygwin will NOT use the NT
security model to set UNIX-like peremissions.

So if you use CYGWIN=nontsec, you are losing some of the UNIX-ness of
your cygwin enviroment.

I still don't understand why Vista (which I do not have a copy of to
test with) would assume that a new folder being created needed to be
shared.

I haven't found a way to display the "shared" status of a folder from
a cygwin bash prompt.

ls and getfacl can give me permission and ownership information, but
not whether or not something is shared.

You can always use the Microsoft net command (see: net help share).

If I understand the problem, when you create a new directory inside a
cygwin shell, the directory is automatically shared (with the little
hand on the icon or whatever Vista uses to show that) and that this
happens whether or not the parent directory is shared.

Meaning, if you did
$ mkdir test1
$ mkdir test2
$ net share
You would see something like
Share name     Resource                       Remark
-------------------------------------------------------------------
ADMIN$         C:\WINDOWS                     Remote Admin
IPC$                                          Remote IPC
test1          C:\cygwin\home\jrd\test1
test2          C:\cygwin\home\jrd\test2

Is this correct?

-Jason

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

[E.Baud]

Hello,

nmehta wrote:

...
Also, if you create a directory in Cygwin on /c like you did it does not show up as shared.  If you create a directory in your Vista home directory (/c/Users/<username>/) on the other hand it shows up as shared.  
...
I can also say that CYGWIN=notntsec does fix this behavior (created folders are no longer shared).
...

Same thing for me: it depends on the current directory... subdirectories of Desktop have also these unexpected shared files/directories generated.

Setting this variable CYGWIN=notntsec (with .bashrc or Vista system environment variables)  is functioning well. No shared tags anymore when creating files/dir from cygwin shell.

But if you compile a c program with cygwin/gcc(3.4.4) that generate files, as this test-one : Stupid-Vista by Georg Nikodym,
then, this variable seems not to be used when the .exe file is not executed from Cygwin-shell (run directly from windows explorer, for example).
And then again appear problems of shared files/directories.
... I tried to call setenv(CYGWIN, nontsec,1) in C file, without success.
[edit] sorry, I forgot to restart windows... that was necessary in order CYGWIN variable to be taken in account. File .exe is now generating files without shared tags [edit]

One other strange thing, is that: if the .exe file is run "as Administrator", then there's no more shared tags !? (my current Vista user is belonging only to Administrators group; so, why is there a difference !?)

Emmanuel.

[Corinna Vinschen-2]

On Nov 20 02:51, E.Baud wrote:

> nmehta wrote:
> > Also, if you create a directory in Cygwin on /c like you did it does not
> > show up as shared.  If you create a directory in your Vista home directory
> > (/c/Users/<username>/) on the other hand it shows up as shared.  
> > ...
> > I can also say that CYGWIN=notntsec does fix this behavior (created
> > folders are no longer shared).
>
> Same thing for me: it depends on the current directory... subdirectories of
> Desktop have also these unexpected shared files/directories generated.
>
> Setting this variable CYGWIN=notntsec (with .bashrc or Vista system
> environment variables)  is functioning well. No shared tags anymore when
> creating files/dir from cygwin shell.

I missed this crucial fact so far.  Now I was able to reproduce it.

It appears that the "shared" tag has nothing to do with sharing in a
network sharing sense.  The "shared" tag attached to files and directories
in your Vista home folder indicates that this file or folder has
permissions which allow a "normal" local user other than yourself to
access this file or directory.

Experimenting with various permission settings, I found that the
"shared" tag only shows up if the file/dir has any combination of ACEs
for the Users group or for Everyone, regardless of the actual
permissions granted in the ACE.

Apparently this is some sort of "security" consideration new in Vista.

Given that, there's nothing Cygwin can do about it.  POSIX permissions
require to have settings for Everyone and, depending on the /etc/passwd
settings, the Users group.  I'm certainly not going to cripple Cygwin's
POSIX permission facility just so that Vista doesn't show this weird
"shared" tag.

There are a couple of ways to go ahead, in the order from good to bad:

- Find out if there's a way to switch off this crappy Vista feature and
  switch it off.

- Move your Cygwin home directory outside of the C:/Users tree.  There's
  no reason to keep the Cygwin home directory in this tree.  I'm using
  C:/cygwin/home/corinna and/or C:/home/corinna for years and I haven't
  had any problems due to that.

- Set CYGWIN=nontsec and lose POSIX permissions.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

[Corinna Vinschen-2]

On Nov 23 13:16, Corinna Vinschen wrote:
> Experimenting with various permission settings, I found that the
> "shared" tag only shows up if the file/dir has any combination of ACEs
> for the Users group or for Everyone, regardless of the actual
> permissions granted in the ACE.

...and for files the "shared" tag is also shown if an ACE for the None
group (resp. Domain Users in domains) is given.  Oh well.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

[Matthew Persico]

On Nov 23, 2007 7:16 AM, Corinna Vinschen <corinna-cygwin@...> wrote:
> - Move your Cygwin home directory outside of the C:/Users tree.  There's
>   no reason to keep the Cygwin home directory in this tree.  I'm using
>   C:/cygwin/home/corinna and/or C:/home/corinna for years and I haven't
>   had any problems due to that.

I'll second that suggestion. Seeing as Cygwin is, techncially, a
"program", it should, at worst, be installed in C:\Program Files. At
best, I put all of my "non windows" stuff (Cygwin, Native built Perl,
native build xemacs, etc) in C:\opt. Then, depending on what I am
doing on a particular box, I rig my Windows home directory to be the
Cygwin home. But, if this thread holds true, we probably shouldn't
even do that anymore on Vista.

>
--
Matthew O. Persico

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

[E.Baud]

In fact, as I wrote it in previous message:
- I'm not concerned about cygwin home/install location, but more with the program I wrote (that generates files and subdirectories), compiled with gcc/cygwin, and that run over images directories (most of the time under Desktop directories). In that case, the setting-up of environment variable CYGWIN=nontsec with such C-call:  setenv(CYGWIN, nontsec,1) is not efficient !?; So, the only solution I have is to set permanent this environment variable (as a vista environment variable), with impact on whole cygwin shells...

moreover,
- the "shared tags" are annoying, and there's a bug? in vista making the deletion of such files, taking too much time

Emmanuel.

[joekrahn]

I have found that Vista tags filesystem objects as "shared" whenever they contain references to any accounts other than the user. But, they are not "network shared". Apparently, Cygwin developers do not see this behavior. Maybe it depends if you use Home or Business versions of Vista, or whether your machine is managed under a domain controller. See my previous message and the reply:
http://cygwin.com/ml/cygwin/2007-11/msg00058.html
http://cygwin.com/ml/cygwin/2007-11/msg00069.html

Here is how this Vista shared thing works on my computer, running Vista Home (Premium?), set with a Workgroup name, but no domain controller. If I create a file in Windows and then add an Everyone ACL with:
ICACLS foo.txt /grant "Everyone:(R)"

I now have a "shared" tag on that file's icon in Windows Explorer, but it is not listed as shared when looking up information on "network shared" files. So, in some contexts, Vista uses the "shared" icon tag to indicate "locally shared" instead of "network shared". The idea of "locally shared" sort of makes sense if a system is not part of an NT domain, and is acting in more of a stand-alone mode. I have looked for documentation on this, but features that are oriented to home users tend to be poorly documented.

In my previous post to this list, I suggested that Cygwin changes it's attribute handling to leave out the local/None and Everyone groups completely, whenever they have no access permissions. In that case, users with this problem can set umask to 077, and the group+world attributes are not needed, so those two ACL entries can be left out. Or, maybe it just needs a different choice for the no-access state. I found that adding an ACL entry with only the AS (access system security) attribute did NOT give the file a shared icon tag.

Seeing the shared icon tag everywhere is only a minor nuisance. The major problem is that manipulating those files from Windows becomes incredibly slow. I tried to move a large directory tree and got completion estimates of about 20 hours. Why so slow?? Maybe the indexing service is confused about the "Everyone" user, and is rebuilding the index for every file moved. In any case, it is probably a design bug. Maybe if we disable the indexing service the performance hit will go away.

As a work-around, it would be easy to create a Perl script that recursively removes the extra file attributes.

E.Baud wrote:

In fact, as I wrote it in previous message:
- I'm not concerned about cygwin home/install location, but more with the program I wrote (that generates files and subdirectories), compiled with gcc/cygwin, and that run over images directories (most of the time under Desktop directories). In that case, the setting-up of environment variable CYGWIN=nontsec with such C-call:  setenv(CYGWIN, nontsec,1) is not efficient !?; So, the only solution I have is to set permanent this environment variable (as a vista environment variable), with impact on whole cygwin shells...

moreover,
- the "shared tags" are annoying, and there's a bug? in vista making the deletion of such files, taking too much time

Emmanuel.