Re: [Libreoffice] [PATCH] installer::archivefiles - remove external find and chmod forks

I just noticed my patch uses 0755 instead of 0775 as well - I'm not sure why
you'd give group write access but that's what the original does.

Regards
Steve

On 20 December 2010 19:22, Tor Lillqvist <tlillqvist@novell.com> wrote:

> > > > On 2010-12-20 at 10:06, <stevenb@kjross.com.au> wrote:
> > Without knowing much about it, I'd assumed that it might have set the
> "Read
> > & Execute" permission on the windows file.
>
> Note that file protection (and protection of all other "objects", too) is
> not anything like the POSIX set of rwx permissions for owner, group and
> others. Windows uses ACLs for evertything. Windows ACLs are very different
> than POSIX and can be boundlessly complex (as opposed to the fixed set of
> mode bits in POSIX). Cygwin programs running on a Windows machine kinda live
> in a separate world from normal Win32 programs running on the machine.
>
> Cygwin, as it is a POSIX emulation layer, or actually more like a hosted
> guest OS layer, has to emulate the POSIX rwxrwxrwx bits by creating such a
> view "out of thin air"  as a "best guess" for existing files. When setting
> the POSIX mode of a new file created by a Cygwin program, or moduifying it
> with the Cygwin chmod() "system call", it has to create a potentially quite
> obscure ACL to get the intended semantic end result as viewed from the
> Cygwin universe.
>
> And when I say obscure, I do mean it; that if you manipulate the same files
> using both Cygwin chmod etc commands, and normal Windows Explorer protection
> setting GUI, you can end up in very weird situations.
>
> As the DLLs in question that the installer-builder handles are not related
> to Cygwin at all, have been created by Win32 programs like the MS linker
> etc, and are to be used by a Win32 program (LibreOffice), I fail to see why
> any manipulation of their (emulated) Cygwin mode would be needed at all.
>
> --tml


-- 
Regards,
Steve Butler