This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Permission denied on a windows share


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]