This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: Permission denied on a windows share
- From: Randall R Schulz <rrschulz at cris dot com>
- To: Jehan <nahor at bravobrava dot com>, cygwin at cygwin dot com
- Date: Sat, 13 Jul 2002 21:00:34 -0700
- Subject: Re: Permission denied on a windows share
- References: <5.1.0.14.2.20020713194509.02bb9210@pop3.cris.com>
Jehan,
At 20:20 2002-07-13, Jehan wrote:
Randall R Schulz wrote:
Jehan,
Move ("mv") doesn't write into files. It manipulates directory entries.
However, mv has to copy the file when you move it accross filesystems,
doesn't it? If the file was on the same partition, I would understand that
it works (cygwin would just ask the filesystem to move the file entry from
one directory to another). But in my case, the initial file is on a local
drive while the destination is a share. It must be copied somehow.
Yes, but mv will always remove the target and then re-create it, either by
linking and unlinking (when the source and destination are the same file
system) or copying and unlinking (the cross-file-system case). Cp will
(attempt to) open an existing file and overwrite it.
Directory permissions and the permissions of the files they contain are
not the same thing--they're mostly independent. An unwritable file is
still removable (or replaceable) if the directory in which it resides
permits writing (to a first approximation, at least).
But if *I* create the file, I should then be able to write to it no?
Not necessarily. On Unix it would depend only on the umask you have set up.
Windows is probably different.
Windows permissions are a lot...fancier than Unix's. Cygwin does its best
to map permissions between the two models, but in the end, it's Windows'
permission scheme that rules the day. Network shares probably complicate
the picture, too, but I'm no expert on either Windows' permission scheme
nor how network shares interact with it.
This should give you the clues on where to look to solve your problem.
Look at the directory's permissions and ownership with "ls -ld" and the
files' with "ls -l".
I know (well I think I know) what is going on. This directory belongs to
the domain user jehan while I'm log as the local user jehan. They are two
different accounts so have different IDs.
But then, I should not be able to *create* the empty file: the directory
also belongs to the domain user.
I'm not sure, but I think that under Windows, creation, removal, reading,
writing, renaming (maybe) are all governed by separate capabilities. Take
this with a grain of salt--as I said, I don't really understand the Windows
permissions scheme.
I should not be able to *read* the files: the windows permission show them
are read/writable only by the domain user.
So cygwin isn't very consistent in it's behavior. It looks like cygwin
relies on Windows for read permission and file creation but manages the
write permission itself. That cygwin tries to set the permission to have a
Unix like behavior ok, but that I don't think it should try to enforce
them, it's Windows reponsability. So I think there is definitely a bug in
cygwin in this regard.
Read the Cygwin Users' Guide for details on the interaction between Cygwin
and Windows permissions. See <http://cygwin.com/cygwin-ug-net/ntsec.html>
and <http://cygwin.com/cygwin-ug-net/using-filemodes.html>. The FAQ
(<http://cygwin.com/faq/faq.html>) contains relevant information, too.
One thing is certain, Cygwin cannot override Windows permissions. If you
can read (or write or remove, etc.) the file from a Cygwin application, you
can read (write, remove) it from a Windows native app. I'm not certain the
reverse is true, however.
Sorry to equivocate so, but since you seemed a little desperate, I figured
I'd try to help.
Jehan
Randall Schulz
Mountain View, CA USA
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/