Re: i686-w64-mingw32-gcc: LC_MESSAGES
On 1/9/19, JonY wrote: > On 1/9/19 7:43 PM, Lee wrote: >>> MSVCR = MicroSoft Visual C Run-time (I think) >> > > Yes, as implemented by msvcrt.dll. cool - makes much more sense now. Thank you! >> Meaning i686-w64-mingw32-gcc uses the Microsoft libraries vs. cygwin >> gcc using posix compliant libraries? Implying LC_MESSAGES not being >> defined is yet another instance of Microsoft not following accepted >> standards? >> > > Cygwin has its own runtime, Windows has its own. Microsoft does whatever > it well pleases, it never did claim POSIX or ISO C compliance. > > See the printf/scanf hacks in mingw. > >> The background for my question is >> https://github.com/htacg/tidy-html5/issues/770 >> Tidy removed the setlocale call from the library init function, so if >> users want a specific locale/language they're going to have to set it >> up themselves. >> I'd like to update the tidylib example code showing how to set the >> language, but >> setlocale(LC_ALL, ""); >> tidySetLanguage( setlocale(LC_MESSAGES, NULL) ); >> probably isn't a good example if LC_MESSAGES is missing on some systems. >> > > Unfortunately, I don't know how that should be implemented on top of a > proprietary runtime layer, or any alternative function calls for that > matter. Me either, which is why I was trying to keep it limited to system calls. But tidySetLanguage( setlocale(LC_ALL, NULL) ); isn't a good idea because setlocale returns a string starting with the value of LC_COLLATE & I suspect there's plenty enough others that prefer ascii sort order to dictionary sort order or whatever it's called. ^shrug^ since it is just example code, if LC_MESSAGES isn't defined maybe just tell them to pick a default & use that... Thanks Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: csih_create_privileged_user - use of SeDenyInteractiveLogonRight
Greetings, Bill Stewart! > Is this correct? In other words, is preventing the account from showing in > the logon screen the _only_ reason for adding SeDenyInteractiveLogonRight? No, SeDenyInteractiveLogon prevents user from creating console sessions, local or remote. This is what service accounts are never supposed to be doing. Yes, by the extension, it will hide the user from welcome screen. -- With best regards, Andrey Repin Thursday, January 10, 2019 3:02:28 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: i686-w64-mingw32-gcc: LC_MESSAGES
On 1/9/19, Brian Inglis wrote: > > On 2019-01-09 12:43, Lee wrote: >> On 1/9/19, Douglas Coup wrote: >>> >>> On 1/9/2019 1:14 PM, Lee wrote: On 1/9/19, JonY wrote: > On 1/8/19 9:26 PM, Lee wrote: >> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/locale.h.html >> has a note for LC_MESSAGES: >> The functionality described is an extension to the ISO C standard. >> Application developers may make use of an extension as it is >> supported on all POSIX.1-2017-conforming systems. >> i686-w64-mingw32-gcc doesn't have LC_MESSAGES defined. >> Is that an oversight, something missing in windows, or .. ?? > Windows MSVCR isn't POSIX nor ISO C compliant, so you shouldn't be > referring to opengroups, only against MSDN. What's a Windows MSVCR? Since the same program compiled with cygwins' gcc has LC_MESSAGES defined, I was guessing it was just a library thing and maybe it just hadn't been implemented in the mingw libraries yet.. but it sounds like it's not an oversight & Microsoft needs to support LC_MESSAGES before i686-w64-mingw32-gcc will. Is that about right? >>> MSVCR = MicroSoft Visual C Run-time (I think) >> Meaning i686-w64-mingw32-gcc uses the Microsoft libraries vs. cygwin >> gcc using posix compliant libraries? Implying LC_MESSAGES not being >> defined is yet another instance of Microsoft not following accepted >> standards? >> The background for my question is >> https://github.com/htacg/tidy-html5/issues/770 >> Tidy removed the setlocale call from the library init function, so if >> users want a specific locale/language they're going to have to set it >> up themselves. >> I'd like to update the tidylib example code showing how to set the >> language, but >> setlocale(LC_ALL, ""); >> tidySetLanguage( setlocale(LC_MESSAGES, NULL) ); >> probably isn't a good example if LC_MESSAGES is missing on some systems. > > You have to convert your messages to Windows message resources in your > build, then link and package Windows message resources with non-POSIX > compliant exes, or add a POSIX message implementation to your exes. I'm just trying to come up with example code for how to set the locale & language in the tidylib documentation; thankfully, me building a native windows version of tidy isn't the goal.. I was just trying out code that worked under cygwin & was a bit surprised it wouldn't even compile for windows. But it seems to be a windows limitation, so [snip snarky comment] Regards, Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Unsubscribing from Cygwin Mailing List (was: iswcntrl() regression)
On 2019-01-08 15:56, Wong, Samuel wrote: > I have tried to unsubscribe from the Cygwin mailing list. > I have tried simple way to unsubscribe by entering Mailing list name, Your > email address. But I cannot find out the mailing list name. > I have read the unsubscribe full, but still cannot find the mailing list name. > Please help to unsubscribe me for all mailing lists with Cygwin. > My email address is samuel.w...@intel.com Mailing list is Cygwin - see: https://cygwin.com/lists.html#subscribe-unsubscribe https://cygwin.com/ml/#unsubscribe-simple also mentioned below. -- 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. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: i686-w64-mingw32-gcc: LC_MESSAGES
On 1/9/19 7:43 PM, Lee wrote: >> MSVCR = MicroSoft Visual C Run-time (I think) > Yes, as implemented by msvcrt.dll. > Meaning i686-w64-mingw32-gcc uses the Microsoft libraries vs. cygwin > gcc using posix compliant libraries? Implying LC_MESSAGES not being > defined is yet another instance of Microsoft not following accepted > standards? > Cygwin has its own runtime, Windows has its own. Microsoft does whatever it well pleases, it never did claim POSIX or ISO C compliance. See the printf/scanf hacks in mingw. > The background for my question is > https://github.com/htacg/tidy-html5/issues/770 > Tidy removed the setlocale call from the library init function, so if > users want a specific locale/language they're going to have to set it > up themselves. > I'd like to update the tidylib example code showing how to set the language, > but > setlocale(LC_ALL, ""); > tidySetLanguage( setlocale(LC_MESSAGES, NULL) ); > probably isn't a good example if LC_MESSAGES is missing on some systems. > > Thanks > Lee > Unfortunately, I don't know how that should be implemented on top of a proprietary runtime layer, or any alternative function calls for that matter. signature.asc Description: OpenPGP digital signature
Re: i686-w64-mingw32-gcc: LC_MESSAGES
On 2019-01-09 12:43, Lee wrote: > On 1/9/19, Douglas Coup wrote: >> >> On 1/9/2019 1:14 PM, Lee wrote: >>> On 1/9/19, JonY wrote: On 1/8/19 9:26 PM, Lee wrote: > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/locale.h.html > has a note for LC_MESSAGES: > The functionality described is an extension to the ISO C standard. > Application developers may make use of an extension as it is > supported on all POSIX.1-2017-conforming systems. > i686-w64-mingw32-gcc doesn't have LC_MESSAGES defined. > Is that an oversight, something missing in windows, or .. ?? Windows MSVCR isn't POSIX nor ISO C compliant, so you shouldn't be referring to opengroups, only against MSDN. >>> What's a Windows MSVCR? >>> Since the same program compiled with cygwins' gcc has LC_MESSAGES >>> defined, I was guessing it was just a library thing and maybe it just >>> hadn't been implemented in the mingw libraries yet.. but it sounds >>> like it's not an oversight & Microsoft needs to support LC_MESSAGES >>> before i686-w64-mingw32-gcc will. Is that about right? >> MSVCR = MicroSoft Visual C Run-time (I think) > Meaning i686-w64-mingw32-gcc uses the Microsoft libraries vs. cygwin > gcc using posix compliant libraries? Implying LC_MESSAGES not being > defined is yet another instance of Microsoft not following accepted > standards? > The background for my question is > https://github.com/htacg/tidy-html5/issues/770 > Tidy removed the setlocale call from the library init function, so if > users want a specific locale/language they're going to have to set it > up themselves. > I'd like to update the tidylib example code showing how to set the language, > but > setlocale(LC_ALL, ""); > tidySetLanguage( setlocale(LC_MESSAGES, NULL) ); > probably isn't a good example if LC_MESSAGES is missing on some systems. You have to convert your messages to Windows message resources in your build, then link and package Windows message resources with non-POSIX compliant exes, or add a POSIX message implementation to your exes. -- 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. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
csih_create_privileged_user - use of SeDenyInteractiveLogonRight
Greetings,
/usr/share/doc/csih/ChangeLog has the following note for 2015-04-02:
* cygwin-service-installation-helper.sh
(csih_create_privileged_user): Also add SeDenyInteractiveLogonRight to the
service user. otherwise it will be shown on the logon screen in some
versions of Windows.
>From this comment, it would seem that the only purpose of adding this user
right ("Deny log on locally") is to hide the user from the logon screen.
Is this correct? In other words, is preventing the account from showing in
the logon screen the _only_ reason for adding SeDenyInteractiveLogonRight?
Thanks,
Bill
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: OpenSSH server on latest Windows 10
On Tue, Jan 8, 2019 at 11:56 PM Jari Fredriksson wrote: > It is indeed removed. There is no ”Cygwin sushi” service any more. I have encountered this as well, but it seems very inconsistent. People on this list who have tried to intentionally reproduce it have been unable to. At the same time, one of my systems is still broken from the Windows Update, and I have been unable to get cygwin ssh working again, and have zero interest in trying the Microsoft ssh. I have delayed updating other systems because of this. -- Erik -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[newlib-cygwin] Cygwin: try_to_bin: fix rootdir handle after reopening
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=b7a6d357ee23d690a6559235600b85801d6ad025 commit b7a6d357ee23d690a6559235600b85801d6ad025 Author: Corinna Vinschen Date: Wed Jan 9 21:41:48 2019 +0100 Cygwin: try_to_bin: fix rootdir handle after reopening If the first rename fails, we reopen the rootdir for creating a subdir. The rootdir handle can change its value at this point, but the code doesn't take this into account. The subsequent rename then fails with STATUS_INVALID_HANDLE. Fix this by copying the new rootdir value to pfri->RootDirectory. Signed-off-by: Corinna Vinschen Diff: --- winsup/cygwin/syscalls.cc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc index 4f91f4b..728a6b1 100644 --- a/winsup/cygwin/syscalls.cc +++ b/winsup/cygwin/syscalls.cc @@ -389,6 +389,8 @@ try_to_bin (path_conv , HANDLE , ACCESS_MASK access, ULONG flags) , status); goto out; } + /* Correct the rootdir HANDLE in pfri after reopening the dir. */ + pfri->RootDirectory = rootdir; /* Then check if recycler exists by opening and potentially creating it. Yes, we can really do that. Typically the recycle bin is created by the first user actually using the bin. */
[newlib-cygwin] Cygwin: try_to_bin: don't check recycler filename all the time
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=fbd3835384fa586fd32ce80280d81bb51ab042ba
commit fbd3835384fa586fd32ce80280d81bb51ab042ba
Author: Corinna Vinschen
Date: Wed Jan 9 21:14:58 2019 +0100
Cygwin: try_to_bin: don't check recycler filename all the time
So far we check the recycler name all the time, and the last interation
also only managed to handle two ways to write the recycler. However,
an adventurous user might change the case of the recycler arbitrarily.
Fix this problem by keeping track of the name in a somewhat relaxed
fashion. Use camel back on drive C by default, all upper case elsewhere.
Only if the rename op fails do we fix the recycler name on the fly
when trying to create it, and it turns out it already existed.
Signed-off-by: Corinna Vinschen
Diff:
---
winsup/cygwin/syscalls.cc | 71 +--
1 file changed, 38 insertions(+), 33 deletions(-)
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index 728a6b1..2628d94 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -195,6 +195,14 @@ enum bin_status
dir_not_empty
};
+/* Typically the recycler on drive C has been created at installation
+ time. The name is then written in camel back. On any other drive,
+ the recycler is created on first usage. shell32.dll then creates
+ the recycler in all upper case. That's only important if the entire
+ operation is running case sensitive. */
+static WCHAR recycler_basename_drive_c[] = L"\\$Recycle.Bin\\";
+static WCHAR recycler_basename_other[] = L"\\$RECYCLE.BIN\\";
+
static bin_status
try_to_bin (path_conv , HANDLE , ACCESS_MASK access, ULONG flags)
{
@@ -205,6 +213,7 @@ try_to_bin (path_conv , HANDLE , ACCESS_MASK access,
ULONG flags)
HANDLE rootdir = NULL, recyclerdir = NULL, tmp_fh = NULL;
USHORT recycler_base_len = 0, recycler_user_len = 0;
UNICODE_STRING root, recycler, fname;
+ PWCHAR recycler_basename = NULL;
WCHAR recyclerbuf[NAME_MAX + 1]; /* Enough for recycler + SID + filename */
PFILE_NAME_INFORMATION pfni;
PFILE_INTERNAL_INFORMATION pfii;
@@ -217,7 +226,8 @@ try_to_bin (path_conv , HANDLE , ACCESS_MASK access,
ULONG flags)
PBYTE infobuf = (PBYTE) tp.w_get ();
pfni = (PFILE_NAME_INFORMATION) infobuf;
- status = NtQueryInformationFile (fh, , pfni, 65536, FileNameInformation);
+ status = NtQueryInformationFile (fh, , pfni, NT_MAX_PATH * sizeof (WCHAR),
+ FileNameInformation);
if (!NT_SUCCESS (status))
{
debug_printf ("NtQueryInformationFile (%S, FileNameInformation) "
@@ -236,7 +246,11 @@ try_to_bin (path_conv , HANDLE , ACCESS_MASK access,
ULONG flags)
RtlInitEmptyUnicodeString (, recyclerbuf, sizeof recyclerbuf);
if (!pc.isremote ())
{
- RtlAppendUnicodeToString (, L"\\$Recycle.Bin\\");
+ recycler_basename = wcsncmp (pc.get_nt_native_path ()->Buffer,
+ L"\\??\\C:\\", 7)
+ ? recycler_basename_other
+ : recycler_basename_drive_c;
+ RtlAppendUnicodeToString (, recycler_basename);
RtlInitCountedUnicodeString(, pfni->FileName,
pfni->FileNameLength);
/* Is the file a subdir of the recycler? */
if (RtlEqualUnicodePathPrefix (, , TRUE))
@@ -287,36 +301,6 @@ try_to_bin (path_conv , HANDLE , ACCESS_MASK access,
ULONG flags)
recycler.Length -= sizeof (WCHAR);
/* Store length of recycler base dir, if it's necessary to create it. */
recycler_base_len = recycler.Length;
- /* The recycler name is $Recycler.Bin by default. If the recycler dir
-disappears for some reason, shell32.dll recreates it in all upper
-case. So we never know if the dir is written in camel back or in
-upper case. That's a problem when using casesensitivity: If the
-file handle given to FileRenameInformation has been opened
-casesensitive, the call also handles the path to the target dir
-casesensitive. Check for the right name here.
-
-Note that, originally, we reopened the file case insensitive instead.
-But that's a problem for O_TMPFILE on pre-W10. As soon as the
-original HANDLE gets closed, delete-on-close is converted to full
-delete disposition and all useful operations on the file cease to
-work (STATUS_ACCESS_DENIED or STATUS_FILE_DELETED). */
- if (!pc.objcaseinsensitive ())
- {
- PFILE_BASIC_INFORMATION pfbi;
-
- InitializeObjectAttributes (, , 0, rootdir, NULL);
- pfbi = (PFILE_BASIC_INFORMATION) infobuf;
- status = NtQueryAttributesFile (, pfbi);
- if (status == STATUS_OBJECT_NAME_NOT_FOUND)
- {
- wcscpy (recycler.Buffer, L"$RECYCLE.BIN\\");
- status = NtQueryAttributesFile (, pfbi);
- /* Keep the uppercase name if it exists,
Re: i686-w64-mingw32-gcc: LC_MESSAGES
On 1/9/19, Douglas Coup wrote: > > On 1/9/2019 1:14 PM, Lee wrote: >> On 1/9/19, JonY wrote: >>> On 1/8/19 9:26 PM, Lee wrote: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/locale.h.html has a note for LC_MESSAGES: The functionality described is an extension to the ISO C standard. Application developers may make use of an extension as it is supported on all POSIX.1-2017-conforming systems. i686-w64-mingw32-gcc doesn't have LC_MESSAGES defined. Is that an oversight, something missing in windows, or .. ?? >>> Windows MSVCR isn't POSIX nor ISO C compliant, so you shouldn't be >>> referring to opengroups, only against MSDN. >> >> What's a Windows MSVCR? >> >> Since the same program compiled with cygwins' gcc has LC_MESSAGES >> defined, I was guessing it was just a library thing and maybe it just >> hadn't been implemented in the mingw libraries yet.. but it sounds >> like it's not an oversight & Microsoft needs to support LC_MESSAGES >> before i686-w64-mingw32-gcc will. Is that about right? >> >> Thanks, >> Lee >> >> > MSVCR = MicroSoft Visual C Run-time (I think) Meaning i686-w64-mingw32-gcc uses the Microsoft libraries vs. cygwin gcc using posix compliant libraries? Implying LC_MESSAGES not being defined is yet another instance of Microsoft not following accepted standards? The background for my question is https://github.com/htacg/tidy-html5/issues/770 Tidy removed the setlocale call from the library init function, so if users want a specific locale/language they're going to have to set it up themselves. I'd like to update the tidylib example code showing how to set the language, but setlocale(LC_ALL, ""); tidySetLanguage( setlocale(LC_MESSAGES, NULL) ); probably isn't a good example if LC_MESSAGES is missing on some systems. Thanks Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: i686-w64-mingw32-gcc: LC_MESSAGES
On 1/9/2019 1:14 PM, Lee wrote: On 1/9/19, JonY wrote: On 1/8/19 9:26 PM, Lee wrote: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/locale.h.html has a note for LC_MESSAGES: The functionality described is an extension to the ISO C standard. Application developers may make use of an extension as it is supported on all POSIX.1-2017-conforming systems. i686-w64-mingw32-gcc doesn't have LC_MESSAGES defined. Is that an oversight, something missing in windows, or .. ?? Windows MSVCR isn't POSIX nor ISO C compliant, so you shouldn't be referring to opengroups, only against MSDN. What's a Windows MSVCR? Since the same program compiled with cygwins' gcc has LC_MESSAGES defined, I was guessing it was just a library thing and maybe it just hadn't been implemented in the mingw libraries yet.. but it sounds like it's not an oversight & Microsoft needs to support LC_MESSAGES before i686-w64-mingw32-gcc will. Is that about right? Thanks, Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple MSVCR = MicroSoft Visual C Run-time (I think) Doug Coup Objective Systems, Inc. REAL WORLD ASN.1 AND XML SOLUTIONS Tel: +1 (484) 875-9841 Fax: +1 (484) 875-9830 Toll-free: (877) 307-6855 (USA only) http://www.obj-sys.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: i686-w64-mingw32-gcc: LC_MESSAGES
On 1/9/19, JonY wrote: > On 1/8/19 9:26 PM, Lee wrote: >> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/locale.h.html >> has a note for LC_MESSAGES: >> The functionality described is an extension to the ISO C standard. >> Application developers may make use of an extension as it is >> supported on all POSIX.1-2017-conforming systems. >> >> i686-w64-mingw32-gcc doesn't have LC_MESSAGES defined. >> Is that an oversight, something missing in windows, or .. ?? >> > > Windows MSVCR isn't POSIX nor ISO C compliant, so you shouldn't be > referring to opengroups, only against MSDN. What's a Windows MSVCR? Since the same program compiled with cygwins' gcc has LC_MESSAGES defined, I was guessing it was just a library thing and maybe it just hadn't been implemented in the mingw libraries yet.. but it sounds like it's not an oversight & Microsoft needs to support LC_MESSAGES before i686-w64-mingw32-gcc will. Is that about right? Thanks, Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
AUTOMATE 2019
Hi, I am following up to check if you are interested in acquiring Attendees List of "AUTOMATE 2019 "? Let me know if you would like to acquire Attendees List? . Attendees List: AUTOMATE 2019. . Total Count: 18,000 Each record in the list contains: - Contact Name, Job Title, Company/Business Name, Email, Tel Number, Website/URL etc. If you are interested, please let me know your thoughts, so that I can send you the no of contacts available and the pricing for it. Awaiting your reply Thanks & Regards, Katherine Allison Lead Generation Note: you were specifically sent this email based upon your company profile, if you do not wish to receive future emails from us, please reply as "No Requirements". -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[newlib-cygwin] Cygwin: rename: use FILE_RENAME_POSIX_SEMANTICS if available
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=ec457e0351eee30c0d7319524e6a1a36f94dfb35 commit ec457e0351eee30c0d7319524e6a1a36f94dfb35 Author: Corinna Vinschen Date: Wed Jan 9 15:47:43 2019 +0100 Cygwin: rename: use FILE_RENAME_POSIX_SEMANTICS if available starting with W10 1709 on local NTFS drives Signed-off-by: Corinna Vinschen Diff: --- winsup/cygwin/release/2.12.0 | 4 winsup/cygwin/syscalls.cc| 30 ++ winsup/doc/new-features.xml | 6 ++ 3 files changed, 36 insertions(+), 4 deletions(-) diff --git a/winsup/cygwin/release/2.12.0 b/winsup/cygwin/release/2.12.0 index 81a55b5..b772782 100644 --- a/winsup/cygwin/release/2.12.0 +++ b/winsup/cygwin/release/2.12.0 @@ -37,6 +37,10 @@ What changed: Deleting an in-use file now actually removes the file, rather than moving it to the recycler bin. +- Use the new POSIX rename semantics on NTFS starting with Windows 10 1709. + Renaming a file to another in-use file now actually removes the other file, + rather than moving it to the recycler bin. + - open(..., O_TMPFILE) now moves the file to the trash bin immediately, to free the parent directory. diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc index 78ac44b..4f91f4b 100644 --- a/winsup/cygwin/syscalls.cc +++ b/winsup/cygwin/syscalls.cc @@ -2216,6 +2216,7 @@ rename2 (const char *oldpath, const char *newpath, unsigned int at2flags) path_conv oldpc, newpc, new2pc, *dstpc, *removepc = NULL; bool old_dir_requested = false, new_dir_requested = false; bool old_explicit_suffix = false, new_explicit_suffix = false; + bool use_posix_semantics; bool noreplace = at2flags & RENAME_NOREPLACE; size_t olen, nlen; bool equal_path; @@ -2511,10 +2512,18 @@ rename2 (const char *oldpath, const char *newpath, unsigned int at2flags) __leave; } + /* POSIX semantics only on local NTFS drives. */ + use_posix_semantics = wincap.has_posix_file_info () + && !oldpc.isremote () + && oldpc.fs_is_ntfs (); + /* Opening the file must be part of the transaction. It's not sufficient to call only NtSetInformationFile under the transaction. Therefore we -have to start the transaction here, if necessary. */ - if ((dstpc->fs_flags () & FILE_SUPPORTS_TRANSACTIONS) +have to start the transaction here, if necessary. Don't start +transaction on W10 1709 or later on local NTFS. Use POSIX semantics +instead. */ + if (!use_posix_semantics + && (dstpc->fs_flags () & FILE_SUPPORTS_TRANSACTIONS) && (dstpc->isdir () || (!removepc && dstpc->has_attribute (FILE_ATTRIBUTE_READONLY start_transaction (old_trans, trans); @@ -2578,6 +2587,9 @@ rename2 (const char *oldpath, const char *newpath, unsigned int at2flags) __leave; } + if (use_posix_semantics) + goto skip_pre_W10_checks; + /* Renaming a dir to another, existing dir fails always, even if ReplaceIfExists is set to TRUE and the existing dir is empty. So we have to remove the destination dir first. This also covers the @@ -2619,6 +2631,8 @@ rename2 (const char *oldpath, const char *newpath, unsigned int at2flags) } } +skip_pre_W10_checks: + /* SUSv3: If the old argument and the new argument resolve to the same existing file, rename() shall return successfully and perform no other action. @@ -2666,7 +2680,13 @@ rename2 (const char *oldpath, const char *newpath, unsigned int at2flags) __leave; } pfri = (PFILE_RENAME_INFORMATION) tp.w_get (); - pfri->ReplaceIfExists = !noreplace; + if (use_posix_semantics) + pfri->Flags = noreplace ? 0 + : (FILE_RENAME_REPLACE_IF_EXISTS + | FILE_RENAME_POSIX_SEMANTICS + | FILE_RENAME_IGNORE_READONLY_ATTRIBUTE); + else + pfri->ReplaceIfExists = !noreplace; pfri->RootDirectory = NULL; pfri->FileNameLength = dstpc->get_nt_native_path ()->Length; memcpy (>FileName, dstpc->get_nt_native_path ()->Buffer, @@ -2677,7 +2697,9 @@ rename2 (const char *oldpath, const char *newpath, unsigned int at2flags) ERROR_ALREADY_EXISTS ==> Cygwin error EEXIST. */ status = NtSetInformationFile (fh, , pfri, sizeof *pfri + pfri->FileNameLength, -FileRenameInformation); +use_posix_semantics +? FileRenameInformationEx +: FileRenameInformation); /* This happens if the access rights don't allow deleting the destination. Even if the handle to the original file is opened with BACKUP and/or
Re: i686-w64-mingw32-gcc: LC_MESSAGES
On 1/8/19 9:26 PM, Lee wrote: > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/locale.h.html > has a note for LC_MESSAGES: > The functionality described is an extension to the ISO C standard. > Application developers may make use of an extension as it is > supported on all POSIX.1-2017-conforming systems. > > i686-w64-mingw32-gcc doesn't have LC_MESSAGES defined. > Is that an oversight, something missing in windows, or .. ?? > Windows MSVCR isn't POSIX nor ISO C compliant, so you shouldn't be referring to opengroups, only against MSDN. signature.asc Description: OpenPGP digital signature
Re: Bash heredoc on FD 3
On Jan 8 16:17, Steven Penny wrote: > On Tue, 8 Jan 2019 22:05:34, Corinna Vinschen wrote: > > I added some changes to make this work in older systems as well. > > I uploaded new snapshots to //cygwin.com/snapshots/ > > > > Please try. > > Confirmed fixed. > > Note I only retested with Windows 7 this time, but I think we’re good. > > Thank you! Thank you for testing! Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
