DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CC0863857C79
From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
Subject: Re: Creating directories without permissions and timestamp on CYGWIN
To: cygwin@cygwin.com
References: <CAK+YOwuJPW=uMoysfPb4ZD=oG8v7dh45UcOz=okOmyCn1isnOA@mail.gmail.com>
 <d3905024-bff7-5e7b-d793-5cabb28d7904@gmail.com>
Autocrypt: addr=Brian.Inglis@SystematicSw.ab.ca; prefer-encrypt=mutual;
 keydata=
 mDMEXopx8xYJKwYBBAHaRw8BAQdAnCK0qv/xwUCCZQoA9BHRYpstERrspfT0NkUWQVuoePa0
 LkJyaWFuIEluZ2xpcyA8QnJpYW4uSW5nbGlzQFN5c3RlbWF0aWNTdy5hYi5jYT6IlgQTFggA
 PhYhBMM5/lbU970GBS2bZB62lxu92I8YBQJeinHzAhsDBQkJZgGABQsJCAcCBhUKCQgLAgQW
 AgMBAh4BAheAAAoJEB62lxu92I8Y0ioBAI8xrggNxziAVmr+Xm6nnyjoujMqWcq3oEhlYGAO
 WacZAQDFtdDx2koSVSoOmfaOyRTbIWSf9/Cjai29060fsmdsDLg4BF6KcfMSCisGAQQBl1UB
 BQEBB0Awv8kHI2PaEgViDqzbnoe8B9KMHoBZLS92HdC7ZPh8HQMBCAeIfgQYFggAJhYhBMM5
 /lbU970GBS2bZB62lxu92I8YBQJeinHzAhsMBQkJZgGAAAoJEB62lxu92I8YZwUBAJw/74rF
 IyaSsGI7ewCdCy88Lce/kdwX7zGwid+f8NZ3AQC/ezTFFi5obXnyMxZJN464nPXiggtT9gN5
 RSyTY8X+AQ==
Organization: Systematic Software
Message-ID: <dd3fd01b-c91f-55c3-e16e-0dad4055170d@SystematicSw.ab.ca>
Date: Mon, 20 Jul 2020 14:46:12 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <d3905024-bff7-5e7b-d793-5cabb28d7904@gmail.com>
Content-Language: en-CA
Precedence: list
Reply-To: cygwin@cygwin.com
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces@cygwin.com
Sender: "Cygwin" <cygwin-bounces@cygwin.com>

On 2020-07-19 14:54, Marco Atzeri via Cygwin wrote:
> On 19.07.2020 21:34, Jayasurya p via Cygwin wrote:
>> This was run on CYGWIN_NT-10.0 NVEBLODKIF 3.1.5(0.340/5/3) 2020-06-01 08:59
>> x86_64 Cygwin
>>
>> Creating a directory using mkdir API on C with 0777 permissions with the
>> name having the following ASCII values causes the directory to be created
>> with no user permissions and no timestamp. Length of the name is 66
>> character long including the terminating NULL character.
>> ASCII values of characters in the string: 96 234 195 186 63 63 50 109 4 84
>> 208 246 186 170 197 33 131 113 134 209 109 251 98 226 179 93 178 32 242 189
>> 236 88 14 107 134 133 93 126 210 61 194 27 209 172 244 15 12 222 9 93 10
>> 149 10 235 157 42 114 125 198 182 96 240 171 164 106 0
>>
>> Unit test case to replicate the scenario
>>
>> #include <stdio.h>
>> #include <sys/stat.h>
>> #include <sys/types.h>
>>
>> int main () {
>> char tempPath[66] = {96, 234, 195, 186, 63, 63, 50, 109, 4, 84, 208, 246,
>> 186, 170, 197, 33, 131, 113, 134, 209, 109, 251, 98, 226, 179, 93, 178, 32,
>> 242, 189, 236, 88, 14, 107, 134, 133, 93, 126, 210, 61, 194, 27, 209, 172,
>> 244, 15, 12, 222, 9, 93, 10, 149, 10, 235, 157, 42, 114, 125, 198, 182, 96,
>> 240, 171, 164, 106, 0};
>> mkdir(tempPath, 0777);
>> return 1;
>> }

No value over 127 is ASCII - a 7 bit character set encoding - perhaps you mean
CP1252 - see cp1252(7). That only applies if you are running Windows, and
mintty, with those character set encodings enabled.

Not seeing any directory information to back up your claim.
In case the encoding is different, please do the equivalent of:

$ ls -ld \`*\?\?2*T*\!*b*j/
$ getfacl \`*\?\?2*T*\!*b*j/
$ icacls "$(cygpath -m \`*\?\?2*T*\!*b*j/)"

There are some names which Windows may or may not prevent creating or
overwriting but could possibly cause problems depending on your system: e.g God
Mode folder GUIDs: *.{.......8-...4-...4-...4-..........12}.

> what encoding is supposed to be ?
> I doubt a file name can accept a linefeed (10)

Cygwin has fewer limitations but interprets your filename according to your
language settings and converts problematic characters to PUA or UTF-8 then
converts those to UTF16LE for Windows calls:

https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-dosdevices

and converts them back to your encoding for display.

These filenames may be inaccessible or not trivially accessible from native
Windows programs, and may not be convertible if you change to any encoding other
than UTF8.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple