On Oct 20 19:29, Corinna Vinschen wrote: > On Oct 20 15:57, Franz Sirl wrote: > > Am 2011-10-20 15:09, schrieb Corinna Vinschen: > > >As I wrote, it's not used, so even if it fails, it's worth a > > >support case with Novell, but it doesn't mean we have to change > > >Cygwin. > > > > It fails with errorcode 0xc0000022, Access denied. > > It might be worth a try to ask the Novell support why this occurs. > This is a bug, IMHO. Since Vista, this call should even be supported > in the Win32 API, using the call > > FILE_BASIC_INFO fbi; > GetFileInformationByHandleEx (fhdl, FileBasicInfo, &fbi, sizeof fbi); > > > >>>- NWFS only supports filenames which follow DOS conventions. That is, > > >>> it does not support filenames with leading spaces or trailing dots and > > >>> spaces. This is only checked for when generating filenames. > > >> > > >>Leading and trailing spaces seem to work, trailing dots fail with > > >>"Permission denied". > > > > > >So we still have to assume that only DOS filenames work. > > > > Hmm, I wonder if I should file at least a low priority enhancement > > request for that. > > > > >>>- NWFS does not support re-opening a file by handle, so it always has to > > >>> be re-opened by name. The only difference here is how the > > >>> OBJECT_ATTRIBUTES is created, with a handle or with a name. > > >> > > >>I've worked with Novell to fix that one for NcFsd, will be in one of > > >>the next releases (IR10 or IR11 I guess). > > > > > >Cool, but I think that NcFsd should still be subsumed under NWFS. > > >The fact that re-opening doesn't quite work isn't such a big problem, > > >and by using the OBJECT_ATTRIBUTES with a name we can support older > > >versions of NcFsd as well. > > > > Older versions of NcFsd have even more problems with Cygwin, so > > supporting them doesn't really make sense. It only works reasonable > > since this years June release. I would prefer to keep this code path > > exercised :-). > > Hmm, that should be possible. But keep in mind that this does not > have a better performance on all filesystems. > > > >Are you ok if I send you an URL to a test DLL via PM for this issue? > > >I would add the "handle NcFsd as NWFS" as well to this DLL, otherwise > > >it would be identical to the latest snapshot, which should be available > > >now, btw. > > > > Sure, PM me the URL. [...] > > Thanks, but not today anymore.
Rather than PM, I've just uploaded a snapshot which adds explicit NcFsd support. Please give it a try. NcFsd is marked as having a buggy Query FileBasicInformation support and as only supporting DOS filenames. It is not marked as having a buggy re-open file support and the comment notes that this is supported starting with IR10, which isn't yet released, AFAICS. But there's one more change: As you observed, NcFsd does not return a STATUS_SHARING_VIOLATION when trying to open the top level directory for DELETE, rather trying to set the delete disposition fails with STATUS_CANNOT_DELETE. When this error occurs, unlink_nt now also checks for NcFsd, and if so, it tries delete-on-close as another method to delete the file/directory. This is just an experiment, so could you please take this snapshot and test your fine testcase under strace on W7/NcFsd and send the strace here? However, IMHO this is a bug in NcFsd, just like the sharing violation in NWFS. Since NcFsd is activaly maintained, it might make sense for you or any other NcFsd user to open a support case for this problem, just like for the FileBasicInformation thingy. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
