Re: Patch to allow trailing dots on managed mounts
Christopher Faylor schrieb: On Fri, Dec 17, 2004 at 07:36:15PM -0500, Christopher Faylor wrote: If /cygdrive/c/cygwin/bin./ls.exe works, then /bin./ls.exe should also work. Or, both should fail. consistent Thinking some more about this, there are really some inconsistencies with the current and proposed behavior that I don't like. Here's a table. Please let me know if I got anything wrong: What Now Pierre's proposal Windows Equiv ls /bin... Works Won't work dir c:\cygwin\bin... doesn't work ls /bin. Works Won't work(?) dir c:\cygwin\bin. works ls /lib/gcc. Works Works(?)dir c:\cygwin\lib\gcc. works ls /lib./gcc. Works Won't work(?) dir c:\cygwin\lib.\gcc. works ls /cygdrive/c/cygwin/bin. Works Works(?)dir c:\cygwin\bin. works ls /bin../ls.exe Won't work Won't work dir c:\cygwin\bin..\ls.exe won't work ls /cygdrive/c/cygwin/bin../ls.exe Won't work Won't work ditto ls /bin/ls.exe... Works Works(?)dir c:\cygwin\bin\ls.exe... works ln -s foo bar. Works*Works** .lnk files with dot extensions allowed If I understand this correctly, I think Pierre's proposal == cygwin's behavior before 2004/4, on all counts. So, in thinking about all of this, I have a radical proposal which I have previously alluded to. path_conv::check could detect the existence of trailing dots or spaces in path components of the output win32 path and set ENOENT in such cases unless the file was associated with either a managed mount or Corinna's proposed posix mount. The rationale for this is that you really can't (except in the symlink case) create a file with a trailing dot so why should we lie and say that you can? This probably is too radical an idea and would result in breakage. So, my alternate thought is that single dots should be silently ignored in all path components. Multiple dots should be ignored in the trailing path component, regardless of whether the file refers to a directory or not, which makes cygwin slightly incompatible with windows. I'm not sure how spaces fall out in the above table. I'm not sure that the same rules should be applied for spaces and dots above. I have no strong opinion in these issues (yet), but please look also at the related ending-colon ':extension' problem on NTFS. Such files are also not listed, but probably should be. listing ADS streams http://cygwin.com/ml/cygwin/2004-11/msg00292.html -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/
Re: Patch to allow trailing dots on managed mounts
Christopher Faylor schrieb: On Sat, Dec 18, 2004 at 04:48:50PM -0500, Igor Pechtchanski wrote: There are two possible interpretations here. One is that Reini is proposing to have Cygwin tools always list alternate streams, in which case you're correct, and it's unrelated to the thread. Another is that colons in filenames on certain Cygwin mounts should not represent alternate streams, but should be different files altogether, and thus should be listed normally. That said, I think Reini's wording implies your interpretation, and thus his suggestion should be in a different thread. There really isn't much that we can do with colons, AFAICT. We certainly can't disallow them in the common case and I don't think there is any FindFirstFile/FindNextFile type API which allows us to easily expose them. Although I can see that it would be nice to have a unifying philosophy here I think the strange behavior of a foo:bar on an NTFS file system is not something that we should worry about right now. Agreed. Some different patch for fhandler_disk_file::readdir() on managed mounts later, when the need arises. readdir() performance will be seriously affected, having to look in all regular files for such attached ADS streams. -- Reini Urban
Re: [Fwd: [que_andrewBOOHyahoo.com: FOLLOWUP: 1.5.12: problems without registry keys]]
Christopher Faylor schrieb: On Mon, Dec 13, 2004 at 01:31:58PM -0500, Pierre A. Humblet wrote: Corinna Vinschen wrote: Is that ok to apply or is there any good reason not to release the muto when get_drive() has finished? I can't see any, FWIW. Oops, please apply ASAP of course. Sounds like I should release 1.5.13 soon. With the new process code? Is the exit status problem already solved? Haven't tested that. Pierre's unlink patch is also not integrated yet. Works fine for me. -- Reini Urban
Re: [PATCH] kill -f
Pierre A. Humblet schrieb: This patch allows kill.exe -f to deal with Win9x pids. Needs the bash internal also a patch like this? 2004-11-03 Pierre Humblet [EMAIL PROTECTED] * kill.cc (forcekill): Do not pass negative pids to cygwin_internal. (main): Make pid a long long and distinguish between pids, gpids (i.e. negative pids) and Win9x pids. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/
Re: [PATCH] kill -f
Pierre A. Humblet schrieb: Reini Urban wrote: Pierre A. Humblet schrieb: This patch allows kill.exe -f to deal with Win9x pids. Needs the bash internal also a patch like this? The bash internal doesn't kill Windows pids, neither on NT nor on 9X. I am not in favor of adding Windows specific frills to bash. /bin/kill is a Cygwin program, its man page says that the -f switch kills Windows pids. oops, my $(man kill) misses this interesting info. because I didn't patch that away in my experimental coreutils. I only remembered --force -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/
Re: [Patch] unlink
Pierre A. Humblet schrieb:
It works on normal files. I haven't tested with the
special names because I forgot how to create them !
Feedback welcome.
works fine on w2k.
attached is a test to create such files.
unlink works fine on these.
didn't test with wchar and unicode files yet, just char.
but coreutils/findutils don't work with unicode files anyway.
(just testing findutils-4.1.20)
On reflection, however, wouldn't it be a little easier just to prepend
the path being deleted with a: \\.\ so that rm nul would eventually
translate to DeleteFile(\\.\c:\foo\null) (I'm not using true C
backslash quoting here)? I don't know if that would work on Windows 9x,
though.
// c++ -I../src/winsup/cygwin -o testcreate testcreate.cc -lntdll
#include winsup.h
#include stdio.h
#include ntdef.h
#include ntdll.h
//#define NTCREATE
#undef NTCREATE
NTSTATUS
NtCreateDirectoryObject(
OUT PHANDLE DirectoryHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes
);
#ifndef NTCREATE
static HANDLE
create (char *path)
{
HANDLE hFile;
char pwd[CYG_MAX_PATH], dev[CYG_MAX_PATH];
int len;
//create (.\\c:\\con);
if (len = GetCurrentDirectoryA (CYG_MAX_PATH, pwd)) {
strcpy(dev, .\\);
strcat(dev, pwd);
strcat(dev, \\);
strcat(dev, path);
}
hFile = CreateFile(dev, // file to create
GENERIC_WRITE, // open for writing
0, // do not share
NULL, // default security
CREATE_ALWAYS, // overwrite existing
FILE_ATTRIBUTE_NORMAL | // normal file
FILE_FLAG_OVERLAPPED, // asynchronous I/O
NULL); // no attr. template
if (hFile == INVALID_HANDLE_VALUE) return 0;
printf(%s created\n, path);
CloseHandle(hFile);
return hFile;
}
#else
static HANDLE
nt_create (WCHAR *wpath)
{
WCHAR pwd[2*CYG_MAX_PATH];
UNICODE_STRING upath = {0, sizeof (wpath), wpath};
//UNICODE_STRING cpath = {0, 2, L.};
int len;
HANDLE x, root = NULL;
OBJECT_ATTRIBUTES attr;
IO_STATUS_BLOCK io;
NTSTATUS status;
if (len = GetCurrentDirectoryW (2*CYG_MAX_PATH, pwd)) {
UNICODE_STRING upwd = {0, sizeof (pwd), pwd};
InitializeObjectAttributes (attr, upwd, OBJ_CASE_INSENSITIVE, NULL, NULL);
NtOpenFile(root, STANDARD_RIGHTS_ALL, attr, io, 0, 0);
}
InitializeObjectAttributes (attr, upath, OBJ_CASE_INSENSITIVE, root, NULL);
//
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devnotes/winprog/ntcreatefile.asp
status = NtCreateFile (x, STANDARD_RIGHTS_ALL, attr, io, NULL,
FILE_ATTRIBUTE_NORMAL,
FILE_SHARE_READ, FILE_OPEN, FILE_DELETE_ON_CLOSE, NULL, 0);
if (!NT_SUCCESS (status))
{
printf(error creating %ls\n, wpath);
return 0;
}
else {
CloseHandle(x);
return x;
}
}
#endif
int main(int argc, char** argv)
{
#ifndef NTCREATE
create (con);
create (com);
create (nul);
create (aux);
create (prn);
create (lpt1);
create (...);
#else
nt_create (Lcon);
nt_create (Lnul);
nt_create (Laux);
nt_create (Lprn);
nt_create (Llpt1);
nt_create (L...);
#endif
return(0);
}
sync() revised
I revised my sync() patch, which compiles and works.
The assignment is on the way.
Still didn't find any package which actually uses that.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
2004-10-29 Reini Urban [EMAIL PROTECTED]
* syscalls.cc (sync): Implement it via cygheap-fdtab and
FlushFileBuffers. Better than a noop.
(sync_worker) Internalized, because dtable::lock is private.
* dtable.h: (dtable::sync_worker) Added as friend for lock().
Index: syscalls.cc
===
RCS file: /cvs/src/src/winsup/cygwin/syscalls.cc,v
retrieving revision 1.349
diff -u -b -r1.349 syscalls.cc
--- syscalls.cc 28 Oct 2004 01:46:01 - 1.349
+++ syscalls.cc 29 Oct 2004 14:43:29 -
@@ -1087,10 +1087,33 @@
return 0;
}
+/* Cygwin internal */
+void __stdcall
+sync_worker ()
+{
+ cygheap-fdtab.lock ();
+
+ /* TODO: check if Admin and iterate over the local volumes instead */
+ fhandler_base *fh;
+ for (int i = 0; i (int) cygheap-fdtab.size; i++)
+if ((fh = cygheap-fdtab[i]) != NULL)
+ {
+#ifdef DEBUGGING
+ debug_printf (syncing fd %d, i);
+#endif
+ if (FlushFileBuffers (fh-get_handle ()) == 0)
+ {
+ __seterrno ();
+ }
+ }
+ cygheap-fdtab.unlock ();
+}
+
/* sync: SUSv3 */
extern C void
sync ()
{
+ sync_worker ();
}
/* Cygwin internal */
Index: dtable.h
===
RCS file: /cvs/src/src/winsup/cygwin/dtable.h,v
retrieving revision 1.30
diff -u -b -r1.30 dtable.h
--- dtable.h21 Mar 2004 17:41:40 - 1.30
+++ dtable.h29 Oct 2004 14:43:29 -
@@ -85,6 +85,7 @@
void delete_archetype (fhandler_base *);
friend void dtable_init ();
friend void __stdcall close_all_files ();
+ friend void __stdcall sync_worker ();
friend class cygheap_fdmanip;
friend class cygheap_fdget;
friend class cygheap_fdnew;
Re: sync(3)
Christopher Faylor schrieb:
On Wed, Oct 27, 2004 at 04:36:17AM +0200, Reini Urban wrote:
Why is this a bad idea?
It's a very limited implementation of what sync is supposed to do but
maybe it's better than nothing.
A slightly more robust method would be to implement an internal cygwin
signal which could be sent to every cygwin process telling it to run
code like the below.
A signal looks better.
Maybe just to its master process, and all its subprocesses and threads?
I didn't check what fd's are actually stored in this heap.
On linux it should just ensure to flush the master inode block.
(makes sense for ext2 probably).
For NTFS Volumes this code would be okay as I read at MSDN.
Wonder what FAT will do. postgresql luckily uses fsync().
Maybe I should check which of our apps actually use sync(3).
exim out of my head.
Of course, that isn't foolproof either since it doesn't affect
non-cygwin processes.
Warning: I didn't test it. Maybe it would be better if someone else
would copy-paste it from close_all_files() as I did and test it.
I just had no guts yet to build my own dll.
Do you have an assignment with Red Hat? If so, I'll check this in.
Not yet, but I'll send a letter this week.
2004-10-27 Reini Urban [EMAIL PROTECTED]
* syscalls.cc (sync): Implement it via cygheap-fdtab and
FlushFileBuffers. Better than a noop.
Index: syscalls.cc
===
RCS file: /cvs/src/src/winsup/cygwin/syscalls.cc,v
retrieving revision 1.345
diff -u -b -r1.345 syscalls.cc
--- syscalls.cc 3 Sep 2004 01:53:12 - 1.345
+++ syscalls.cc 27 Oct 2004 02:30:01 -
@@ -1082,6 +1082,24 @@
extern C void
sync ()
{
+ int err = 0;
+ cygheap-fdtab.lock ();
+
+ fhandler_base *fh;
+ for (int i = 0; i (int) cygheap-fdtab.size; i++)
+if ((fh = cygheap-fdtab[i]) != NULL)
+ {
+#ifdef DEBUGGING
+ debug_printf (syncing fd %d, i);
+#endif
+ if (FlushFileBuffers (fh-get_handle ()) == 0)
+ {
+ __seterrno ();
+ err++;
+ }
+ }
+ cygheap-fdtab.unlock ();
+ return err ? 1 : 0;
}
/* Cygwin internal */
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
sync(3)
Why is this a bad idea?
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
2004-10-27 Reini Urban [EMAIL PROTECTED]
* syscalls.cc (sync): Implement it via cygheap-fdtab and
FlushFileBuffers. Better than a noop.
Index: syscalls.cc
===
RCS file: /cvs/src/src/winsup/cygwin/syscalls.cc,v
retrieving revision 1.345
diff -u -b -r1.345 syscalls.cc
--- syscalls.cc 3 Sep 2004 01:53:12 - 1.345
+++ syscalls.cc 27 Oct 2004 02:30:01 -
@@ -1082,6 +1082,24 @@
extern C void
sync ()
{
+ int err = 0;
+ cygheap-fdtab.lock ();
+
+ fhandler_base *fh;
+ for (int i = 0; i (int) cygheap-fdtab.size; i++)
+if ((fh = cygheap-fdtab[i]) != NULL)
+ {
+#ifdef DEBUGGING
+ debug_printf (syncing fd %d, i);
+#endif
+ if (FlushFileBuffers (fh-get_handle ()) == 0)
+ {
+ __seterrno ();
+ err++;
+ }
+ }
+ cygheap-fdtab.unlock ();
+ return err ? 1 : 0;
}
/* Cygwin internal */
