When acl() returns -1

Dave Korn dave.korn@artimi.com
Mon Jun 27 14:40:00 GMT 2005

----Original Message----
>From: Corinna Vinschen
>Sent: 27 June 2005 15:28

> 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

  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....

More information about the Cygwin-developers mailing list