This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
When acl() returns -1
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-developers at cygwin dot com
- Date: Mon, 27 Jun 2005 16:27:58 +0200
- Subject: When acl() returns -1
- Reply-to: cygwin-developers at cygwin dot com
Hi,
I was wondering what you guys think about this:
$ ls -l /cygdrive/c/pagefile.sys
ls: /mnt/c/pagefile.sys: Device or resource busy
---------- 1 ???????? ???????? 804495360 Jun 26 19:50 /mnt/c/pagefile.sys
The error message is printed by ls because a call to acl() returned -1.
It does so because fhandler_disk_file::facl() can't open the file and
NtCreateFile (and, FWIW, GetFileSecurity) returns ERROR_SHARING_VIOLATION
when trying to open pagefile.sys or hiberfil.sys. Actually this happens
when trying to ls any file locked exclusively by another process.
I had this idea that acl() could fake acl entries instead of returning -1,
the same as on non-NTFS file systems. This would obviously make the ls
output of C: cleaner, but OTOH the idea of *faking* acl entries on NTFS
coils up my toe nails.
So what's your opinion? Should acl()
keep its behaviour since it's not worth to change it for these files
which are locked anyway?
or should acl()
return the correct number of faked acl entries which pretend that
nobody has access to these (locked) files?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader mailto:cygwin@cygwin.com
Red Hat, Inc.