Mail Archives: cygwin/2002/07/13/23:59:38
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/
- Raw text -