This is the mail archive of the
mailing list for the Cygwin project.
RE: When acl() returns -1
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: <cygwin-developers at cygwin dot com>
- Date: Mon, 27 Jun 2005 15:40:18 +0100
- Subject: RE: When acl() returns -1
>From: Corinna Vinschen
>Sent: 27 June 2005 15:28
> 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?
How about keeping acl() the same, and fixing 'ls'?
ISTM that ls has all the information it should need to DTRT - a successful
call to stat(), a return value of -1 from acl() and (I would hope that)
errno has EACCES from the ERROR_SHARING_VIOLATION return should let it
deduce 'the file exists but is locked', shouldn't it?
Can't think of a witty .sigline today....