Re: Oddities with file deletion on CIFS drive

2010-09-13 Thread Corinna Vinschen
On Sep 12 15:08, Quanah Gibson-Mount wrote:
 --On Sunday, September 12, 2010 2:21 PM -0700 Quanah Gibson-Mount wrote:
 
 Hi Corinna,
 
 I will give the snapshot a test.  Here is the output of attrib:
 
 bu...@zre-win-002
 /cygdrive/z/current/WINDOWS/ZDESKTOP-608/20100912050101_ZDESKTOP/ZimbraBu
 ild/templates
 $ attrib BUILD_ISYNC_template
 AR
 Z:\current\WINDOWS\ZDESKTOP-608\20100912050101_ZDESKTOP\ZimbraBuild\templ
 ates\BUILD_ISYNC_template
 
 Hi Corinna,
 
 With the snapshot in place, I can now remove the files.
 
 With plain rm, it prompts (as it should) and succeeds if I answer yes.
 With rm -f, no prompt, and it succeeds.

I'm glad to read that, so my hunch was right.


Thanks for testing,
Corinna

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

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



Re: Oddities with file deletion on CIFS drive

2010-09-12 Thread Corinna Vinschen
On Sep 11 12:41, Corinna Vinschen wrote:
 On Sep 10 10:48, Quanah Gibson-Mount wrote:
  --On Friday, September 10, 2010 7:09 PM +0200 Corinna Vinschen wrote:
  
  Let me know if there is anything else I can provide.
  
  I'm not sure.  I don't think so.  The problem is that the unlink(2)
  function in Cygwin does not get any error code from any of the OS
  functions it calls.  So, from the Cygwin POV everything worked fine.
  How is it supposed to know that anything has gone wrong, if the
  underlying OS doesn't tell?
  
  Heh, magic I guess.  If I mount the drive as a CIFS drive from a Linux box,
  I can delete the files just fine, so for now that gives me a workaround
  (I'll move my deletion process to a Linux box).
 
 This morning I had an idea.  While we were looking into the ACL, we
 neglected the DOS attributes.  When you call `attrib' on one of the
 files for which you didn't call chmod yet, is the R/O attribute set?
 
 If so, it *could* explain why Cygwin thought it has successfully deleted
 the file, but it hasn't.  I also might have a workaround for this.

I've checked in a change which probably fixed your issue.  The only
exception are Cygwin symlinks of the old .lnk type, which has more
than one link.  That should occur rather seldom.  Please test the
next developer's snapshot from http://cygwin.com/snapshots/


Thanks,
Corinna

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

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



Re: Oddities with file deletion on CIFS drive

2010-09-12 Thread Quanah Gibson-Mount

--On Sunday, September 12, 2010 1:43 PM +0200 Corinna Vinschen wrote:


On Sep 11 12:41, Corinna Vinschen wrote:

On Sep 10 10:48, Quanah Gibson-Mount wrote:
 --On Friday, September 10, 2010 7:09 PM +0200 Corinna Vinschen wrote:

  Let me know if there is anything else I can provide.
 
  I'm not sure.  I don't think so.  The problem is that the unlink(2)
  function in Cygwin does not get any error code from any of the OS
  functions it calls.  So, from the Cygwin POV everything worked fine.
  How is it supposed to know that anything has gone wrong, if the
  underlying OS doesn't tell?

 Heh, magic I guess.  If I mount the drive as a CIFS drive from a Linux
 box, I can delete the files just fine, so for now that gives me a
 workaround (I'll move my deletion process to a Linux box).

This morning I had an idea.  While we were looking into the ACL, we
neglected the DOS attributes.  When you call `attrib' on one of the
files for which you didn't call chmod yet, is the R/O attribute set?

If so, it *could* explain why Cygwin thought it has successfully deleted
the file, but it hasn't.  I also might have a workaround for this.


I've checked in a change which probably fixed your issue.  The only
exception are Cygwin symlinks of the old .lnk type, which has more
than one link.  That should occur rather seldom.  Please test the
next developer's snapshot from http://cygwin.com/snapshots/


Hi Corinna,

I will give the snapshot a test.  Here is the output of attrib:

bu...@zre-win-002 
/cygdrive/z/current/WINDOWS/ZDESKTOP-608/20100912050101_ZDESKTOP/ZimbraBuild/templates

$ attrib BUILD_ISYNC_template
AR 
Z:\current\WINDOWS\ZDESKTOP-608\20100912050101_ZDESKTOP\ZimbraBuild\templates\BUILD_ISYNC_template



--Quanah


--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

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



Re: Oddities with file deletion on CIFS drive

2010-09-12 Thread Quanah Gibson-Mount

--On Sunday, September 12, 2010 2:21 PM -0700 Quanah Gibson-Mount wrote:


Hi Corinna,

I will give the snapshot a test.  Here is the output of attrib:

bu...@zre-win-002
/cygdrive/z/current/WINDOWS/ZDESKTOP-608/20100912050101_ZDESKTOP/ZimbraBu
ild/templates
$ attrib BUILD_ISYNC_template
AR
Z:\current\WINDOWS\ZDESKTOP-608\20100912050101_ZDESKTOP\ZimbraBuild\templ
ates\BUILD_ISYNC_template


Hi Corinna,

With the snapshot in place, I can now remove the files.

With plain rm, it prompts (as it should) and succeeds if I answer yes.
With rm -f, no prompt, and it succeeds.

--Quanah


--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

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



Re: Oddities with file deletion on CIFS drive

2010-09-11 Thread Corinna Vinschen
On Sep 10 10:48, Quanah Gibson-Mount wrote:
 --On Friday, September 10, 2010 7:09 PM +0200 Corinna Vinschen wrote:
 
 Let me know if there is anything else I can provide.
 
 I'm not sure.  I don't think so.  The problem is that the unlink(2)
 function in Cygwin does not get any error code from any of the OS
 functions it calls.  So, from the Cygwin POV everything worked fine.
 How is it supposed to know that anything has gone wrong, if the
 underlying OS doesn't tell?
 
 Heh, magic I guess.  If I mount the drive as a CIFS drive from a Linux box,
 I can delete the files just fine, so for now that gives me a workaround
 (I'll move my deletion process to a Linux box).

This morning I had an idea.  While we were looking into the ACL, we
neglected the DOS attributes.  When you call `attrib' on one of the
files for which you didn't call chmod yet, is the R/O attribute set?

If so, it *could* explain why Cygwin thought it has successfully deleted
the file, but it hasn't.  I also might have a workaround for this.


Corinna

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

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



Re: Oddities with file deletion on CIFS drive

2010-09-10 Thread Corinna Vinschen
On Sep  8 15:17, Quanah Gibson-Mount wrote:
 I have a CIFS drive I connect to as the windows user.  I can write
 to the drive with no problem.  However, when I go to delete files
 from the drive, Cygwin behaves very oddly.
 
 bu...@zre-win-002 
 /cygdrive/z/current/WINDOWS/main/20100908131458_ZDESKTOP/ZimbraBuild/templates
 $ rm -f *

If you call rm w/o the -f flag, what error message do you get?
Just a simple Permission denied, I guess.

 bu...@zre-win-002 
 /cygdrive/z/current/WINDOWS/main/20100908131458_ZDESKTOP/ZimbraBuild/templates
 $ ls -l
 total 104
 -r-xr-xr-x 1   1362 2010-09-08 13:31 BUILD_EVO_template
 -r-xr-xr-x 1   1453 2010-09-08 13:31 BUILD_ISYNC_template
 [...]
 Now, if I modify the file to be +w, then -w, so it returns to its
 original permissions, I can suddenly delete it:

Did you create the files with a Cygwin aplication or with a native Win32
application?  In theory, there's nothing mysterious here, if the
permissions of the file are so that the DELETE permission for your user
or group is missing in the file's ACL.  For obvious reasons the POSIX
permission bits can't reflect the complexity of the original NT ACL.
The chmod +w/-w somehow overwrite the original permissions with POSIX
permissions as Cygwin generates them and the result is more DELETE
friendly.  Did you try to compare the ACL before and after the chmod?
The output of `cacls filename' is probably different.

 This behavior is quite bizarre.  I should be able to delete the
 files I created with the -f option to rm.

Well, in theory, yes.  However, it's possible that your CIFS drive
has semantics which disallow this with the original ACL for some
reason.  Can you pleae run `strace -o rm.trace rm some_file' on a
file which has the original ACL (before the chmod call) and send the
rm.trace file?


Corinna

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

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



Re: Oddities with file deletion on CIFS drive

2010-09-10 Thread Quanah Gibson-Mount

--On Friday, September 10, 2010 11:16 AM +0200 Corinna Vinschen  wrote:


On Sep  8 15:17, Quanah Gibson-Mount wrote:

I have a CIFS drive I connect to as the windows user.  I can write
to the drive with no problem.  However, when I go to delete files
from the drive, Cygwin behaves very oddly.

bu...@zre-win-002
/cygdrive/z/current/WINDOWS/main/20100908131458_ZDESKTOP/ZimbraBuild/tem
plates $ rm -f *


If you call rm w/o the -f flag, what error message do you get?
Just a simple Permission denied, I guess.


Nope.  It doesn't give any error.

bu...@zre-win-002 
/cygdrive/z/current/WINDOWS/main/20100908131458_ZDESKTOP/ZimbraBuild/templates

$ rm BUILD_ISYNC_template
rm: remove write-protected regular file `BUILD_ISYNC_template'? y

bu...@zre-win-002 
/cygdrive/z/current/WINDOWS/main/20100908131458_ZDESKTOP/ZimbraBuild/templates

$ ls -l BUILD_ISYNC_template
-r-xr-xr-x 1   1453 2010-09-08 13:31 BUILD_ISYNC_template


bu...@zre-win-002
/cygdrive/z/current/WINDOWS/main/20100908131458_ZDESKTOP/ZimbraBuild/tem
plates $ ls -l
total 104
-r-xr-xr-x 1   1362 2010-09-08 13:31 BUILD_EVO_template
-r-xr-xr-x 1   1453 2010-09-08 13:31 BUILD_ISYNC_template
[...]
Now, if I modify the file to be +w, then -w, so it returns to its
original permissions, I can suddenly delete it:


Did you create the files with a Cygwin aplication or with a native Win32
application?  In theory, there's nothing mysterious here, if the
permissions of the file are so that the DELETE permission for your user
or group is missing in the file's ACL.  For obvious reasons the POSIX
permission bits can't reflect the complexity of the original NT ACL.
The chmod +w/-w somehow overwrite the original permissions with POSIX
permissions as Cygwin generates them and the result is more DELETE
friendly.  Did you try to compare the ACL before and after the chmod?
The output of `cacls filename' is probably different.


The files are created with a native Win32 application (Perforce), where it 
is checking these files out of the Perforce repository.


Here is the output from cacls prior to +w/-w:
bu...@zre-win-002 
/cygdrive/z/current/WINDOWS/main/20100908131458_ZDESKTOP/ZimbraBuild/templates

$ cacls BUILD_ISYNC_template
Z:\current\WINDOWS\main\20100908131458_ZDESKTOP\ZimbraBuild\templates\BUILD_ISYNC_template
Everyone:F
Account Domain not foundF
Account Domain not foundR
Everyone:R


Here is cacls after +w/-w:
Z:\current\WINDOWS\main\20100908131458_ZDESKTOP\ZimbraBuild\templates\BUILD_ISYNC_template 
Account Domain not found(special access:)


STANDARD_RIGHTS_ALL

DELETE

READ_CONTROL

WRITE_DAC

WRITE_OWNER

SYNCHRONIZE

STANDARD_RIGHTS_REQUIRED

FILE_GENERIC_READ

FILE_GENERIC_EXECUTE

FILE_READ_DATA

FILE_READ_EA

FILE_EXECUTE

FILE_READ_ATTRIBUTES

FILE_WRITE_ATTRIBUTES


Account Domain not foundR

Everyone:R



This behavior is quite bizarre.  I should be able to delete the
files I created with the -f option to rm.


Well, in theory, yes.  However, it's possible that your CIFS drive
has semantics which disallow this with the original ACL for some
reason.  Can you pleae run `strace -o rm.trace rm some_file' on a
file which has the original ACL (before the chmod call) and send the
rm.trace file?


Done.  I've provided strace output from both rm FILE and rm -f FILE

Let me know if there is anything else I can provide.

--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

rm.trace.gz
Description: Binary data


rmf.trace.gz
Description: Binary data
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Oddities with file deletion on CIFS drive

2010-09-10 Thread Corinna Vinschen
On Sep 10 09:47, Quanah Gibson-Mount wrote:
 The files are created with a native Win32 application (Perforce),
 where it is checking these files out of the Perforce repository.
 
 Here is the output from cacls prior to +w/-w:
 bu...@zre-win-002 
 /cygdrive/z/current/WINDOWS/main/20100908131458_ZDESKTOP/ZimbraBuild/templates
 $ cacls BUILD_ISYNC_template
 Z:\current\WINDOWS\main\20100908131458_ZDESKTOP\ZimbraBuild\templates\BUILD_ISYNC_template
 Everyone:F
 Account Domain not foundF
 Account Domain not foundR
 Everyone:R

These permissions look very weird.

 Here is cacls after +w/-w:
 Z:\current\WINDOWS\main\20100908131458_ZDESKTOP\ZimbraBuild\templates\BUILD_ISYNC_template
 Account Domain not found(special access:)
 
 STANDARD_RIGHTS_ALL
 
 DELETE
 
 READ_CONTROL
 
 WRITE_DAC
 
 WRITE_OWNER
 
 SYNCHRONIZE
 
 STANDARD_RIGHTS_REQUIRED
 
 FILE_GENERIC_READ
 
 FILE_GENERIC_EXECUTE
 
 FILE_READ_DATA
 
 FILE_READ_EA
 
 FILE_EXECUTE
 
 FILE_READ_ATTRIBUTES
 
 FILE_WRITE_ATTRIBUTES
 
 
 Account Domain not foundR
 
 Everyone:R

This looks better.  The fact that the accounts can't be found is
probably because it's running Samba and the drives are not real NTFS, so
the SIDs returned by Samba are the artificial SIDs generated from the
Unix uid/gid.  Btw., just because the Unix user is called build, it's
not necessariliy the same user as the Windows user build.  Actually,
if you don't use Samba with winbind and only use WIndows users from AD
on both machines, the accounts are different.

 Done.  I've provided strace output from both rm FILE and rm -f FILE
 
 Let me know if there is anything else I can provide.

I'm not sure.  I don't think so.  The problem is that the unlink(2)
function in Cygwin does not get any error code from any of the OS
functions it calls.  So, from the Cygwin POV everything worked fine.
How is it supposed to know that anything has gone wrong, if the
underlying OS doesn't tell?


Corinna

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

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



Re: Oddities with file deletion on CIFS drive

2010-09-10 Thread Quanah Gibson-Mount

--On Friday, September 10, 2010 7:09 PM +0200 Corinna Vinschen wrote:


Let me know if there is anything else I can provide.


I'm not sure.  I don't think so.  The problem is that the unlink(2)
function in Cygwin does not get any error code from any of the OS
functions it calls.  So, from the Cygwin POV everything worked fine.
How is it supposed to know that anything has gone wrong, if the
underlying OS doesn't tell?


Heh, magic I guess.  If I mount the drive as a CIFS drive from a Linux box,
I can delete the files just fine, so for now that gives me a workaround
(I'll move my deletion process to a Linux box).

--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration
Zimbra ::  the leader in open source messaging and collaboration

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



Re: Oddities with file deletion on CIFS drive

2010-09-09 Thread Quanah Gibson-Mount
--On Wednesday, September 08, 2010 10:50 PM -0400 Larry Hall (Cygwin) 
reply-to-list-only...@cygwin.com wrote:



Yeah, there's been plenty of these network appliances that really foul up
their implementation of permissions.  MVFS and NetApp are a couple in the
past that have had problems.  If you have the csih package installed, run
/usr/lib/csih/getVolInfo drive letter:/ and send the results here.  And
then wait for the groans. ;-)


Ok, here is the results. ;)

$ /usr/lib/csih/getVolInfo /cygdrive/z
Device Type: 7
Characteristics: 10
Volume Name: 121
Serial Number  : 27
Max Filenamelength : 255
Filesystemname : NTFS
Flags  : 4007e
 FILE_CASE_SENSITIVE_SEARCH  : FALSE
 FILE_CASE_PRESERVED_NAMES   : TRUE
 FILE_UNICODE_ON_DISK: TRUE
 FILE_PERSISTENT_ACLS: TRUE
 FILE_FILE_COMPRESSION   : TRUE
 FILE_VOLUME_QUOTAS  : TRUE
 FILE_SUPPORTS_SPARSE_FILES  : TRUE
 FILE_SUPPORTS_REPARSE_POINTS: FALSE
 FILE_SUPPORTS_REMOTE_STORAGE: FALSE
 FILE_VOLUME_IS_COMPRESSED   : FALSE
 FILE_SUPPORTS_OBJECT_IDS: FALSE
 FILE_SUPPORTS_ENCRYPTION: FALSE
 FILE_NAMED_STREAMS  : TRUE
 FILE_READ_ONLY_VOLUME   : FALSE
 FILE_SEQUENTIAL_WRITE_ONCE  : FALSE
 FILE_SUPPORTS_TRANSACTIONS  : FALSE

--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

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



Oddities with file deletion on CIFS drive

2010-09-08 Thread Quanah Gibson-Mount
I have a CIFS drive I connect to as the windows user.  I can write to the 
drive with no problem.  However, when I go to delete files from the drive, 
Cygwin behaves very oddly.


bu...@zre-win-002 
/cygdrive/z/current/WINDOWS/main/20100908131458_ZDESKTOP/ZimbraBuild/templates

$ rm -f *

bu...@zre-win-002 
/cygdrive/z/current/WINDOWS/main/20100908131458_ZDESKTOP/ZimbraBuild/templates

$ ls -l
total 104
-r-xr-xr-x 1   1362 2010-09-08 13:31 BUILD_EVO_template
-r-xr-xr-x 1   1453 2010-09-08 13:31 BUILD_ISYNC_template
-r-xr-xr-x 1    636 2010-09-08 13:31 BUILD_LABEL_template
-r-xr-xr-x 1   1536 2010-09-08 13:31 
BUILD_WIN_UPDATE_template

-r-xr-xr-x 1   1699 2010-09-08 13:31 BUILD_template
-r-xr-xr-x 1   4508 2010-09-08 13:31 BUILD_template_FOSS
-r-xr-xr-x 1   7118 2010-09-08 13:31 
BUILD_template_FOSS_ThirdParty

-r-xr-xr-x 1   1453 2010-09-08 13:31 BUILD_template_ISYNC
-r-xr-xr-x 1   5535 2010-09-08 13:31 BUILD_template_NETWORK
-r-xr-xr-x 1   7975 2010-09-08 13:31 
BUILD_template_NETWORK_ThirdParty

-r-xr-xr-x 1   1463 2010-09-08 13:31 BUILD_template_TOASTER
-r-xr-xr-x 1   2989 2010-09-08 13:31 BUILD_template_ZDESKTOP
-r-xr-xr-x 1   1386 2010-09-08 13:31 BUILD_test

Even with -f, it failed to delete these files.  Files that were created by 
this very user.


Now, if I modify the file to be +w, then -w, so it returns to its original 
permissions, I can suddenly delete it:


bu...@zre-win-002 
/cygdrive/z/current/WINDOWS/main/20100908131458_ZDESKTOP/ZimbraBuild/templates

$ chmod a+w BUILD_EVO_template

bu...@zre-win-002 
/cygdrive/z/current/WINDOWS/main/20100908131458_ZDESKTOP/ZimbraBuild/templates

$ chmod a-w BUILD_EVO_template

bu...@zre-win-002 
/cygdrive/z/current/WINDOWS/main/20100908131458_ZDESKTOP/ZimbraBuild/templates

$ rm BUILD_EVO_template

bu...@zre-win-002 
/cygdrive/z/current/WINDOWS/main/20100908131458_ZDESKTOP/ZimbraBuild/templates

$ ls -l
total 96
-r-xr-xr-x 1   1453 2010-09-08 13:31 BUILD_ISYNC_template
-r-xr-xr-x 1    636 2010-09-08 13:31 BUILD_LABEL_template
-r-xr-xr-x 1   1536 2010-09-08 13:31 
BUILD_WIN_UPDATE_template

-r-xr-xr-x 1   1699 2010-09-08 13:31 BUILD_template
-r-xr-xr-x 1   4508 2010-09-08 13:31 BUILD_template_FOSS
-r-xr-xr-x 1   7118 2010-09-08 13:31 
BUILD_template_FOSS_ThirdParty

-r-xr-xr-x 1   1453 2010-09-08 13:31 BUILD_template_ISYNC
-r-xr-xr-x 1   5535 2010-09-08 13:31 BUILD_template_NETWORK
-r-xr-xr-x 1   7975 2010-09-08 13:31 
BUILD_template_NETWORK_ThirdParty

-r-xr-xr-x 1   1463 2010-09-08 13:31 BUILD_template_TOASTER
-r-xr-xr-x 1   2989 2010-09-08 13:31 BUILD_template_ZDESKTOP
-r-xr-xr-x 1   1386 2010-09-08 13:31 BUILD_test


This behavior is quite bizarre.  I should be able to delete the files I 
created with the -f option to rm.


--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

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



Re: Oddities with file deletion on CIFS drive

2010-09-08 Thread Quanah Gibson-Mount
--On Wednesday, September 08, 2010 3:17 PM -0700 Quanah Gibson-Mount  
wrote:





This behavior is quite bizarre.  I should be able to delete the files I
created with the -f option to rm.




Also, if I mount it on a linux box via CIFS, I can delete files on this 
drive no issue.  So it is definitely a Cygwin issue.


--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

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



Re: Oddities with file deletion on CIFS drive

2010-09-08 Thread Larry Hall (Cygwin)

On 9/8/2010 6:17 PM, Quanah Gibson-Mount wrote:

I have a CIFS drive I connect to as the windows user.  I can write to the
drive with no problem. However, when I go to delete files from the drive,
Cygwin behaves very oddly.


snip


$ ls -l
total 104
-r-xr-xr-x 1   1362 2010-09-08 13:31 BUILD_EVO_template


snip

I think you need to look at why the user that created the files in the
first place isn't known to Cygwin.  If you can solve that problem, you
may find the rest falls into place.

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - 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?


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



Re: Oddities with file deletion on CIFS drive

2010-09-08 Thread Quanah Gibson-Mount
--On Wednesday, September 08, 2010 6:37 PM -0400 Larry Hall (Cygwin)  
wrote:



$ ls -l
total 104
-r-xr-xr-x 1   1362 2010-09-08 13:31 BUILD_EVO_template


snip

I think you need to look at why the user that created the files in the
first place isn't known to Cygwin.  If you can solve that problem, you
may find the rest falls into place.


No clue, I assume it is some bug in cygwin, since this happens to any file 
created on this drive via Cygwin.


bu...@zre-win-002 /cygdrive/z/current/WINDOWS
$ whoami
build

bu...@zre-win-002 /cygdrive/z/current/WINDOWS
$ ls -l blah
ls: cannot access blah: No such file or directory

bu...@zre-win-002 /cygdrive/z/current/WINDOWS
$ touch blah
l
bu...@zre-win-002 /cygdrive/z/current/WINDOWS
$ ls -l blah
-rw-r--r-- 1   0 2010-09-08 15:45 blah

bu...@zre-win-002 /cygdrive/z/current/WINDOWS
$ rm blah

bu...@zre-win-002 /cygdrive/z/current/WINDOWS
$


--Quanah



--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

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



Re: Oddities with file deletion on CIFS drive

2010-09-08 Thread Larry Hall (Cygwin)

On 9/8/2010 6:45 PM, Quanah Gibson-Mount wrote:

--On Wednesday, September 08, 2010 6:37 PM -0400 Larry Hall (Cygwin)  wrote:


snip


I think you need to look at why the user that created the files in the
first place isn't known to Cygwin. If you can solve that problem, you
may find the rest falls into place.


No clue, I assume it is some bug in cygwin, since this happens to any file
created on this drive via Cygwin.

bu...@zre-win-002 /cygdrive/z/current/WINDOWS
$ whoami
build

bu...@zre-win-002 /cygdrive/z/current/WINDOWS
$ ls -l blah
ls: cannot access blah: No such file or directory

bu...@zre-win-002 /cygdrive/z/current/WINDOWS
$ touch blah
l
bu...@zre-win-002 /cygdrive/z/current/WINDOWS
$ ls -l blah
-rw-r--r-- 1   0 2010-09-08 15:45 blah


OK, take a look at http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-ids.
You'll want to use 'mkpasswd' and 'mkgroup' to get the passwd and group
files fixed up.

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - 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?


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



Re: Oddities with file deletion on CIFS drive

2010-09-08 Thread Quanah Gibson-Mount
--On Wednesday, September 08, 2010 6:51 PM -0400 Larry Hall (Cygwin)  
wrote:




OK, take a look at http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-ids.
You'll want to use 'mkpasswd' and 'mkgroup' to get the passwd and group
files fixed up.


I've read that page multiple times, and it still looks greek to me. :/ 
What I know is, the CIFS drive is mounted as the user build.  The user I 
log into windows with is build.  The user cygwin runs under is build. 
So all 3 of those match.  I don't see why there's any issue at all 
determining who owns the files.


bu...@zre-win-002 ~
$ id build
uid=503(build) gid=513(None) groups=513(None)

bu...@zre-win-002 ~
$ grep build /etc/passwd
build:unused:503:513:U-ZRE-WIN-002\build,S-1-5-21-1229272821-2049760794-1417001333-1003:/home/build:/bin/bash

bu...@zre-win-002 ~
$ grep 513 /etc/group
None:S-1-5-21-1229272821-2049760794-1417001333-513:513:

--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

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



Re: Oddities with file deletion on CIFS drive

2010-09-08 Thread Larry Hall (Cygwin)

On 9/8/2010 7:07 PM, Quanah Gibson-Mount wrote:

--On Wednesday, September 08, 2010 6:51 PM -0400 Larry Hall (Cygwin)  wrote:



OK, take a look at http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-ids.
You'll want to use 'mkpasswd' and 'mkgroup' to get the passwd and group
files fixed up.


I've read that page multiple times, and it still looks greek to me. :/ What I
know is, the CIFS drive is mounted as the user build. The user I log into
windows with is build. The user cygwin runs under is build. So all 3 of
those match. I don't see why there's any issue at all determining who owns
the files.

bu...@zre-win-002 ~
$ id build
uid=503(build) gid=513(None) groups=513(None)

bu...@zre-win-002 ~
$ grep build /etc/passwd
build:unused:503:513:U-ZRE-WIN-002\build,S-1-5-21-1229272821-2049760794-1417001333-1003:/home/build:/bin/bash


This shouldn't be significant but is there a reason that you changed
your uid to 503 from 1003?


bu...@zre-win-002 ~
$ grep 513 /etc/group
None:S-1-5-21-1229272821-2049760794-1417001333-513:513:


Hm, what does 'ls -ln' look like?  I can guess but I shouldn't do that. ;-)

That covers all the obvious things for me.  I'd recommend taking a look at
the SAMBA server to see if user IDs are mapped correctly.  Also, I know
there were some problems in the past with older Samba servers, bugs and
all.  Make sure you're using a current version there.  It may be
worthwhile to look at the permissions and owners from the Windows
perspective too.  If that doesn't get you anywhere, I'd recommend filing
a full problem report on your follow-up to the list.  See the link below
for full details:


Problem reports: http://cygwin.com/problems.html



--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - 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?


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



Re: Oddities with file deletion on CIFS drive

2010-09-08 Thread Quanah Gibson-Mount
--On Wednesday, September 08, 2010 9:55 PM -0400 Larry Hall (Cygwin)  
wrote:



bu...@zre-win-002 ~
$ id build
uid=503(build) gid=513(None) groups=513(None)

bu...@zre-win-002 ~
$ grep build /etc/passwd
build:unused:503:513:U-ZRE-WIN-002\build,S-1-5-21-1229272821-2049760794-
1417001333-1003:/home/build:/bin/bash


This shouldn't be significant but is there a reason that you changed
your uid to 503 from 1003?


503 is what we usually use for the build user on our linux boxes, I had 
changed it to see if it would do anything ownership wise, but it didn't.  I 
changed it back to 1003 and rebooted, but no change in behavior.



bu...@zre-win-002 ~
$ grep 513 /etc/group
None:S-1-5-21-1229272821-2049760794-1417001333-513:513:


Hm, what does 'ls -ln' look like?  I can guess but I shouldn't do that.
;-)



-r-xr-xr-x 1 4294967295 4294967295 1453 2010-09-08 13:31 
BUILD_ISYNC_template


(etc)


That covers all the obvious things for me.  I'd recommend taking a look at
the SAMBA server to see if user IDs are mapped correctly.  Also, I know
there were some problems in the past with older Samba servers, bugs and
all.  Make sure you're using a current version there.  It may be
worthwhile to look at the permissions and owners from the Windows
perspective too.  If that doesn't get you anywhere, I'd recommend filing
a full problem report on your follow-up to the list.  See the link below
for full details:


I don't think the CIFS server is using Samba, actually.  It is a Celerra 
storage array from EMC 
(http://www.emc.com/products/family/celerra-family.htm), and in this 
case, it isn't hooked up to an AD server like they usually have them.



Problem reports: http://cygwin.com/problems.html


Ok, thanks.

--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

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



Re: Oddities with file deletion on CIFS drive

2010-09-08 Thread Quanah Gibson-Mount
--On Wednesday, September 08, 2010 7:12 PM -0700 Quanah Gibson-Mount 
qua...@zimbra.com wrote:



That covers all the obvious things for me.  I'd recommend taking a look
at the SAMBA server to see if user IDs are mapped correctly.  Also, I
know there were some problems in the past with older Samba servers, bugs
and all.  Make sure you're using a current version there.  It may be
worthwhile to look at the permissions and owners from the Windows
perspective too.  If that doesn't get you anywhere, I'd recommend filing
a full problem report on your follow-up to the list.  See the link below
for full details:


I don't think the CIFS server is using Samba, actually.  It is a Celerra
storage array from EMC
(http://www.emc.com/products/family/celerra-family.htm), and in this
case, it isn't hooked up to an AD server like they usually have them.


Hm, looks like it does use smb, based off google.  But I have no idea what 
version of Samba it ships with.  I'll see if I can find out from out 
networking team.


--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

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



Re: Oddities with file deletion on CIFS drive

2010-09-08 Thread Larry Hall (Cygwin)

On 9/8/2010 10:21 PM, Quanah Gibson-Mount wrote:

--On Wednesday, September 08, 2010 7:12 PM -0700 Quanah Gibson-Mount
qua...@zimbra.com wrote:


That covers all the obvious things for me. I'd recommend taking a look
at the SAMBA server to see if user IDs are mapped correctly. Also, I
know there were some problems in the past with older Samba servers, bugs
and all. Make sure you're using a current version there. It may be
worthwhile to look at the permissions and owners from the Windows
perspective too. If that doesn't get you anywhere, I'd recommend filing
a full problem report on your follow-up to the list. See the link below
for full details:


I don't think the CIFS server is using Samba, actually. It is a Celerra
storage array from EMC
(http://www.emc.com/products/family/celerra-family.htm), and in this
case, it isn't hooked up to an AD server like they usually have them.


Hm, looks like it does use smb, based off google. But I have no idea what
version of Samba it ships with. I'll see if I can find out from out
networking team.


Yeah, there's been plenty of these network appliances that really foul up
their implementation of permissions.  MVFS and NetApp are a couple in the
past that have had problems.  If you have the csih package installed, run
/usr/lib/csih/getVolInfo drive letter:/ and send the results here.  And
then wait for the groans. ;-)

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - 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?


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