Re: Size limitation for NcFsd drive?
Am 2016-08-05 um 11:30 schrieb Corinna Vinschen: On Aug 4 20:31, Franz Sirl wrote: Sorry for the delay, for some reason my users keep me busy with strange bugs, see my answers below. I know what you mean :) Am 2016-08-02 um 16:59 schrieb Corinna Vinschen: Hi Franz, On Aug 2 16:26, Franz Sirl wrote: Nevertheless I believe the fallback to NtQueryDirectoryFile(FileIdBothDirectoryInformation) does not do what you want if the path is the root directory of a share. But that's not the cause of this problem. Yeah, as I wrote in my reply, the NtQueryDirectoryFile branch isn't supposed to be hit in this scenario. It's solely for "access denied" situations. Got it. Are you set up to build your own Cygwin DLL so you can test the above patch locally? Not really, but since I've already created a few testcases for Novell now, I have my own little "framework" using ntdll.dll directly. I added your code to it and it showed: C:\NovellQueryAllInformationFile\Debug>NovellQueryAllInformationFile.exe t:\ NtQueryInformationFile(FileAllInformation) 't:\' resulted in errorcode c7e90006, description: (no description) Returned filename: '' NtQueryInformationFile(FileBasicInformation) 't:\' resulted in errorcode 0, description: STATUS_WAIT_0 NtQueryInformationFile(FileStandardInformation) 't:\' resulted in errorcode 0, description: STATUS_WAIT_0 So your fallback will work nicely. No idea if it's worth it, because I'll likely get an updated NCP client soon from Novell. Ok, thank you. I applied a patch nevertheless, because we can never be really sure there won't be another filesystems with the same problem. I uploaded a new developer snapshot to https://cygwin.com/snapshots/ which contains my fix. It would be nice if you could give it a try. Hi Corinna, the snapshot fixes the problem nicely, thanks! Franz -- 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: Size limitation for NcFsd drive?
Sorry for the delay, for some reason my users keep me busy with strange bugs, see my answers below. Am 2016-08-02 um 16:59 schrieb Corinna Vinschen: Hi Franz, On Aug 2 16:26, Franz Sirl wrote: Nevertheless I believe the fallback to NtQueryDirectoryFile(FileIdBothDirectoryInformation) does not do what you want if the path is the root directory of a share. But that's not the cause of this problem. Yeah, as I wrote in my reply, the NtQueryDirectoryFile branch isn't supposed to be hit in this scenario. It's solely for "access denied" situations. Got it. Are you set up to build your own Cygwin DLL so you can test the above patch locally? Not really, but since I've already created a few testcases for Novell now, I have my own little "framework" using ntdll.dll directly. I added your code to it and it showed: C:\NovellQueryAllInformationFile\Debug>NovellQueryAllInformationFile.exe t:\ NtQueryInformationFile(FileAllInformation) 't:\' resulted in errorcode c7e90006, description: (no description) Returned filename: '' NtQueryInformationFile(FileBasicInformation) 't:\' resulted in errorcode 0, description: STATUS_WAIT_0 NtQueryInformationFile(FileStandardInformation) 't:\' resulted in errorcode 0, description: STATUS_WAIT_0 So your fallback will work nicely. No idea if it's worth it, because I'll likely get an updated NCP client soon from Novell. Franz. -- 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: Size limitation for NcFsd drive?
Am 2016-07-29 um 16:38 schrieb Corinna Vinschen: On Jul 29 16:18, Corinna Vinschen wrote: In the first place it would be prudent to find out why the FileAllInformation info class fails on this drive. And in the second place it would be important to find out how to fix this. Potential checks: - Buffer alignment of the FILE_ALL_INFORMATION member in class path_conv_handle. - Buffer size of the FILE_ALL_INFORMATION member. For instance, does it work if the buffer is 1 byte bigger? Or perhaps if the buffer is NAME_MAX bigger? - There's also a chance (albeit minor) that the FileAllInformation call actually worked and the weird status code is just wrong. After all, returning from this call with STATUS_BUFFER_OVERFLOW is valid, too, so I'd check for this as well here. Hi Corinna, no, the error code isn't influenced by alignment or size. For local drives and SMB shares the STATUS_BUFFER_OVERFLOW turns into STATUS_SUCCESS as soon as there is enough room for the share path in the FILE_NAME_INFORMATION.FileName flexible array member (actually, why isn't path_conv_handle.attribs._fai larger? performance? FileNameInformation usually not needed?). But for the NCP share the strange error code for FileAllInformation remains. Checking all the members of FileAllInformation one by one, it turned out that it's the FileInternalIformation member that fails. I've reported it as a bug to Novell. Nevertheless I believe the fallback to NtQueryDirectoryFile(FileIdBothDirectoryInformation) does not do what you want if the path is the root directory of a share. But that's not the cause of this problem. Franz. -- 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: Size limitation for NcFsd drive?
Am 2016-07-28 um 21:58 schrieb Corinna Vinschen: On Jul 28 17:33, Franz Sirl wrote: Hi, some more hints. A colleague reported it still works with Cygwin-2.0.4. And for some reason only the toplevel doesn't work (seems it's not detected as a directory): fsirl@FRAPC4 ~ $ ls -l /cygdrive/ total 87 d---r-x---+ 1 NT SERVICE+TrustedInstaller NT SERVICE+TrustedInstaller 0 Jul 28 15:06 c drwxrwx---+ 1 SYSTEM SYSTEM 0 Jul 20 12:43 d drwxr-xr-x 1 fsirl Domain Users 0 Aug 2 2011 f drwxr-xr-x 1 fsirl Domain Users 0 Jan 12 2016 g drwxr-xr-x 1 fsirl Domain Users 0 Mrz 27 2015 h drwxr-xr-x 1 fsirl Domain Users 0 Dez 15 2014 i drwxr-xr-x 1 fsirl Domain Users 0 Jun 30 08:05 j drwxr-xr-x 1 fsirl Domain Users 0 Jul 28 15:01 l drwxr-xr-x 1 fsirl DE 0 Jul 28 14:38 n -rw-r--r-- 1 fsirl Domain Users 67948 Jul 25 19:53 t fsirl@FRAPC4 ~ $ ls -ld /cygdrive/t/. ls: cannot access '/cygdrive/t/.': Not a directory fsirl@FRAPC4 ~ $ ls -ld /cygdrive/t/dvd-branch/. drwxr-xr-x 1 fsirl Domain Users 0 Jun 11 01:08 /cygdrive/t/dvd-branch/. Could it be permissions? Can you send the output of `icacls T:'? Other than that, an strace of `ls -ld /cygdrive/t/.' might give a clue. Hi Corinna, no, it's not permissions, it's the order in which files are returned for directory enumeration. There is this code snippet around line ~2800 in path.cc: RtlSplitUnicodePath (&upath, &dirname, &basename); status = NtQueryDirectoryFile (dir, NULL, NULL, NULL, &io, &fdi_buf, sizeof fdi_buf, FileIdBothDirectoryInformation, TRUE, &basename, TRUE); /* Take the opportunity to check file system while we're having the handle to the parent dir. */ fs.update (&upath, dir); NtClose (dir); It tries to query the first entry returned and assumes (no idea if Windows guarantees that, POSIX does not AFAIK) that it is ".". But in my case for this drive it is just some file that happens to be first in the directory enumeration. And then everything goes wrong from there. The related strace excerpt shows: 1788 764507 [main] ls 7456 lstat64: entering 45 764552 [main] ls 7456 normalize_posix_path: src /cygdrive/t/. 44 764596 [main] ls 7456 normalize_posix_path: /cygdrive/t/ = normalize_posix_path (/cygdrive/t/.) 42 764638 [main] ls 7456 mount_info::conv_to_win32_path: conv_to_win32_path (/cygdrive/t) 49 764687 [main] ls 7456 mount_info::cygdrive_win32_path: src '/cygdrive/t', dst 'T:\' 46 764733 [main] ls 7456 set_flags: flags: binary (0x2) 44 764777 [main] ls 7456 mount_info::conv_to_win32_path: src_path /cygdrive/t, dst T:\, flags 0x4022, rc 0 372 765149 [main] ls 7456 symlink_info::check: 0x0 = NtCreateFile (\??\T:\) 316 765465 [main] ls 7456 symlink_info::check: 0xC7E90006 = NtQueryInformationFile (\??\T:\) 1573 767038 [main] ls 7456 symlink_info::check: not a symlink 64 767102 [main] ls 7456 symlink_info::check: 0 = symlink.check(T:\, 0xB6E0) (0x404022) 65 767167 [main] ls 7456 path_conv::check: T:\ is a non-directory 44 767211 [main] ls 7456 stat_worker: got 20 error from path_conv 43 767254 [main] ls 7456 __set_errno: int stat_worker(path_conv&, stat*):1857 setting errno 20 54 767308 [main] ls 7456 stat_worker: -1 = (\??\T:\,0x60004AC40) So upath was likely "\??\T:\" and I guess RtlSplitUnicodePath() returned "" or "*.*" for basename. Maybe a possible fix/workaround would be to force basename to "." in this case? Does anyone know if the NtQueryDirectoryFile() spec makes any guarantees about the order of the returned entries? And, as an explanation, this happened because during the copying of this share the filesystem was changed from pure ext3 to ext3 with dir_index enabled. With dir_index enabled the directory entries are enumerated in an order dictated by the hashing I guess. I turned of the dir_index feature and Cygwin started working normally again on this drive. But note that it only works because now "a directory" is returned as first entry, but it seems it's usually not "." with NcFsd. Seems like it worked by accident before. Franz -- 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: Size limitation for NcFsd drive?
Hi, some more hints. A colleague reported it still works with Cygwin-2.0.4. And for some reason only the toplevel doesn't work (seems it's not detected as a directory): fsirl@FRAPC4 ~ $ ls -l /cygdrive/ total 87 d---r-x---+ 1 NT SERVICE+TrustedInstaller NT SERVICE+TrustedInstaller 0 Jul 28 15:06 c drwxrwx---+ 1 SYSTEM SYSTEM 0 Jul 20 12:43 d drwxr-xr-x 1 fsirl Domain Users 0 Aug 2 2011 f drwxr-xr-x 1 fsirl Domain Users 0 Jan 12 2016 g drwxr-xr-x 1 fsirl Domain Users 0 Mrz 27 2015 h drwxr-xr-x 1 fsirl Domain Users 0 Dez 15 2014 i drwxr-xr-x 1 fsirl Domain Users 0 Jun 30 08:05 j drwxr-xr-x 1 fsirl Domain Users 0 Jul 28 15:01 l drwxr-xr-x 1 fsirl DE 0 Jul 28 14:38 n -rw-r--r-- 1 fsirl Domain Users 67948 Jul 25 19:53 t fsirl@FRAPC4 ~ $ ls -ld /cygdrive/t/. ls: cannot access '/cygdrive/t/.': Not a directory fsirl@FRAPC4 ~ $ ls -ld /cygdrive/t/dvd-branch/. drwxr-xr-x 1 fsirl Domain Users 0 Jun 11 01:08 /cygdrive/t/dvd-branch/. Franz. -- 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
Size limitation for NcFsd drive?
Hi, yesterday I enlarged one share of a OES-Server to 4.87TB. After that it seems the drive mapped to this share is no longer properly visible in at least CygWin 2.5.[12]/2.6.0-0.3. An old installation with 1.7.35 works still fine. For T: (failing) and L: (ok, hosted on the same server) getVolInfo shows the following: fsirl@FRAPC4 ~ $ /usr/lib/csih/getVolInfo.exe /cygdrive/t Device Type: 7 Characteristics: 30 Volume Name: Serial Number : 1549022002 Max Filenamelength : 255 Filesystemname : Flags : a2 FILE_CASE_SENSITIVE_SEARCH : FALSE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: FALSE FILE_PERSISTENT_ACLS: FALSE FILE_FILE_COMPRESSION : FALSE FILE_VOLUME_QUOTAS : TRUE FILE_SUPPORTS_SPARSE_FILES : FALSE FILE_SUPPORTS_REPARSE_POINTS: TRUE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: FALSE FILE_SUPPORTS_ENCRYPTION: FALSE FILE_NAMED_STREAMS : FALSE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE fsirl@FRAPC4 ~ $ /usr/lib/csih/getVolInfo.exe /cygdrive/l Device Type: 7 Characteristics: 30 Volume Name: Serial Number : 1548508996 Max Filenamelength : 255 Filesystemname : Flags : a2 FILE_CASE_SENSITIVE_SEARCH : FALSE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: FALSE FILE_PERSISTENT_ACLS: FALSE FILE_FILE_COMPRESSION : FALSE FILE_VOLUME_QUOTAS : TRUE FILE_SUPPORTS_SPARSE_FILES : FALSE FILE_SUPPORTS_REPARSE_POINTS: TRUE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: FALSE FILE_SUPPORTS_ENCRYPTION: FALSE FILE_NAMED_STREAMS : FALSE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE fsirl@FRAPC4 ~ $ df /cygdrive/t /cygdrive/l Filesystem 1K-blocks Used Available Use% Mounted on T: 5147067816 1790728936 3356338880 35% /cygdrive/t L: 103303536 86715812 16587724 84% /cygdrive/l fsirl@FRAPC4 ~ $ ls /cygdrive/t/ /cygdrive/l/ ls: cannot access '/cygdrive/t/': Not a directory /cygdrive/l/: automail automail-lowpriority drive_l.mrk forward intranet mailing officeuploads rep support temp www wwwdir wwwlogs wwwuploads What can I do to track this down? regards, Franz Sirl -- 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: [ANNOUNCEMENT] Updated: make-4.1-1
Am 2015-02-19 um 20:19 schrieb Ti Strga: BLUF: either the new make package needs cygltdl-7 as one of its dependencies, or Guile does, so that setup.exe can Do The Right Thing. I updated to make-4.1-1 and the executable immediately broke: $ make --version /usr/bin/make.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory Poked the current cygcheck at it: $ cygcheck /usr/bin/make.exe C:\cygwin\bin\make.exe C:\cygwin\bin\cygwin1.dll C:\Windows\system32\KERNEL32.dll C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll C:\Windows\system32\ntdll.dll C:\Windows\system32\KERNELBASE.dll C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-IO-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-SysInfo-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Localization-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-String-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Debug-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ErrorHandling-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Fibers-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Util-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Profile-L1-1-0.dll C:\Windows\system32\API-MS-Win-Security-Base-L1-1-0.dll C:\cygwin\bin\cygguile-17.dll C:\cygwin\bin\cygcrypt-0.dll C:\cygwin\bin\cyggmp-3.dll C:\cygwin\bin\cyggcc_s-1.dll C:\cygwin\bin\cygintl-8.dll C:\cygwin\bin\cygiconv-2.dll cygcheck: track_down: could not find cygltdl-7.dll Hi, I had the same problem, but installing cygltdl-7.dll didn't fix it: $ cygcheck.exe /usr/bin/make C:\cygwin\bin\make.exe C:\cygwin\bin\cygwin1.dll C:\Windows\system32\KERNEL32.dll C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll C:\Windows\system32\ntdll.dll C:\Windows\system32\KERNELBASE.dll C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-IO-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-SysInfo-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Localization-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-String-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Debug-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ErrorHandling-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Fibers-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Util-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Profile-L1-1-0.dll C:\Windows\system32\API-MS-Win-Security-Base-L1-1-0.dll C:\cygwin\bin\cygguile-17.dll C:\cygwin\bin\cygcrypt-0.dll C:\cygwin\bin\cygintl-8.dll C:\cygwin\bin\cygiconv-2.dll C:\cygwin\bin\cygltdl-7.dll cygcheck: track_down: could not find cyggmp-3.dll $ dir /usr/bin/cyggmp* /usr/bin/cyggmp-10.dll And I can't seem to find cyggmp-3.dll anywhere anymore? BTW, a minor wish, I would appreciate it if the make-package would be a bit more like the Linux distributions and also provide /usr/bin/gmake in addition to /usr/bin/make. Thanks, Franz -- 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: Another call for filesystem testing
The results for NcFsd (with NovellClient 2 SP2): $ uname -s CYGWIN_NT-6.1-WOW64 $ /usr/lib/csih/getVolInfo //OESI2/VOL_MISC1 Device Type: 7 Characteristics: 30 Volume Name: Serial Number : 1549160268 Max Filenamelength : 255 Filesystemname : Flags : a2 FILE_CASE_SENSITIVE_SEARCH : FALSE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: FALSE FILE_PERSISTENT_ACLS: FALSE FILE_FILE_COMPRESSION : FALSE FILE_VOLUME_QUOTAS : TRUE FILE_SUPPORTS_SPARSE_FILES : FALSE FILE_SUPPORTS_REPARSE_POINTS: TRUE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: FALSE FILE_SUPPORTS_ENCRYPTION: FALSE FILE_NAMED_STREAMS : FALSE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE $ ./test-qfif.exe /cygdrive/j/FRA/ /cygdrive/j/FRA/xyz.tst NtQueryFullAttributesFile(\??\J:\FRA) by name works NtQueryFullAttributesFile(\??\J:\FRA) by handle works NtQueryFullAttributesFile(\??\J:\FRA\xyz.tst) by name works NtQueryFullAttributesFile(\??\J:\FRA\xyz.tst) by handle works and for NWFS (with NovellClient 4.91 SP5 IR1 + followup patches): $ uname -s CYGWIN_NT-5.1 $ /usr/lib/csih/getVolInfo.exe //oesi2/vol_misc1 Device Type: 7 Characteristics: 30 Volume Name: Serial Number : 167772417 Max Filenamelength : 255 Filesystemname : Flags : 2 FILE_CASE_SENSITIVE_SEARCH : FALSE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: FALSE FILE_PERSISTENT_ACLS: FALSE FILE_FILE_COMPRESSION : FALSE FILE_VOLUME_QUOTAS : FALSE FILE_SUPPORTS_SPARSE_FILES : FALSE FILE_SUPPORTS_REPARSE_POINTS: FALSE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: FALSE FILE_SUPPORTS_ENCRYPTION: FALSE FILE_NAMED_STREAMS : FALSE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE $ ./test-qfif.exe /cygdrive/j/FRA/ /cygdrive/j/FRA/xyz.txt NtQueryFullAttributesFile(\??\J:\FRA) by name works NtQueryFullAttributesFile(\??\J:\FRA) by handle failed, status code 0xc008 NtQueryFullAttributesFile(\??\J:\FRA\xyz.txt) by name failed, status code 0xc034 NtOpenFile(\??\J:\FRA\xyz.txt) failed, status code 0xc034 Franz. -- 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: rm -rf cannot delete the upmost directory level anymore on a Novell share
Am 2011-10-24 12:31, schrieb Corinna Vinschen: On Oct 24 12:11, Franz Sirl wrote: Am 2011-10-21 17:35, schrieb Corinna Vinschen: On Oct 21 16:58, Franz Sirl wrote: I will create a support case with Novell. To make my understanding clear, I think there are actually 2 problems here (Win32 calls for illustration, assuming the directory is already opened): 0. The directory has been opened with all sharing modes allowed "elsewhere". 1. CreateFile(FILE_READ_ATTRIBUTES | DELETE, FILE_SHARE_DELETE) should not succeed, but fail with STATUS_SHARING_VIOLATION I didn't see a full strace from W7. Did you check that this doesn't happen anyway? strace attached. Succeeding here depends on the access modes of the open handle(s) or if the directory is not open at all. That's why I added the step 0. But if the file is open elsewhere, this step should not succeed based on the access modes, but only based on the sharing modes allowed by the other handle. Not exactly, at least on W7. For example FILE_SHARE_READ doesn't seem to matter without FILE_READ_DATA. Your changes work, I just tried the 20111023 snapshot. See the attached strace on Win7/64. Thanks, it looks like expected now, given NcFsd's behaviour. Note that this can't be fixed on NWFS. On NWFS, only the changes to upstream coreutils as outlined in http://cygwin.com/ml/cygwin/2011-10/msg00481.html will help. Yes, I noticed that one too, thanks. Any idea when the fix will show up in Cygwin's coreutils? I also attached the simple testcase I'll submit to Novell. Please let me know if you think something is wrong with the testcase. Looks good to me. For completeness, maybe you should note that delete-on-close works in this scenario, but it's desired that both methods work, just as on NTFS, for instance. Good idea, done. Thanks for your help! Franz. -- 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: rm -rf cannot delete the upmost directory level anymore on a Novell share
Am 2011-10-21 11:10, schrieb Corinna Vinschen: 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 0xc022, 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); This succeeds?? Arrgh, looking at my testcase again, I see that I only used NtOpenFile(WRITE_ATTRIBUTES | DELETE). I reused my code to test the read-only file deletion, but forgot to change this, sorry. As soon as I added READ_ATTRIBUTES, the testcase using NtQueryInformationFile(FileBasicInformation) succeeded. - 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. FileBasicInformation, isn't buggy anymore, see above. 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? The functionality works (directory is deleted), but an error is reported anyway: rm-8.4: cannot remove `lev1': Directory not empty The corresponding strace looks like: 242 240405 [main] rm-8.4 6088 unlink_nt: Trying to delete \??\J:\FRA\test_rm_rf\lev1, isdir = 1 1004 241409 [main] rm-8.4 6088 unlink_nt: Setting delete disposition on \??\J:\FRA\test_rm_rf\lev1 failed, status = 0xC121 263 241672 [main] rm-8.4 6088 unlink_nt: Cannot delete \??\J:\FRA\test_rm_rf\lev1, try delete-on-close 1272 242944 [main] rm-8.4 6088 unlink_nt: \??\J:\FRA\test_rm_rf\lev1, return status = 0x0 1754 244698 [main] rm-8.4 6088 seterrno_from_nt_status: /ext/build/netrel/src/cygwin-snapshot-20111021-1/winsup/cygwin/fhandler_disk_file.cc:1735 status 0xC101 -> windows error 145 266 244964 [main] rm-8.4 6088 geterrno_from_win_error: windows error 145 == errno 90 237 245201 [main] rm-8.4 6088 rmdir: -1 = rmdir (/test_rm_rf/lev1) I guess this error is from fhandler_disk_file::rmdir(). 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. I will create a support case with Novell. To make my understanding clear, I think there are actually 2 problems here (Wi
Re: rm -rf cannot delete the upmost directory level anymore on a Novell share
Am 2011-10-20 15:09, schrieb Corinna Vinschen: On Oct 20 13:50, Franz Sirl wrote: Am 2011-10-20 11:20, schrieb Corinna Vinschen: On Oct 19 18:43, Franz Sirl wrote: True. But on the other hand NWFS and NcFsd exercise a lot of pathes in the Cygwin sourcecode that aren't usually used. Not really a lot. NWFS is known to have three problems: - The NtQueryInformationFile(FileBasicInformation) call fails. This call is only used in circumstance which don't affect NWFS. I think that still fails with NcFsd, I'll check it. 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 0xc022, Access denied. - 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 :-). $ mount F: on /cygdrive/f type ncfsd (binary,posix=0,user,noumount,auto) Ok, so it's not subsumed under any other filesystem. I'll change that in CVS to handle NcFsd identical to NWFS. $ /usr/lib/csih/getVolInfo /cygdrive/j Device Type: 7 Characteristics: 30 Volume Name: Serial Number : 1549160268 Max Filenamelength : 255 Filesystemname : Flags : a2 FILE_CASE_SENSITIVE_SEARCH : FALSE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: FALSE FILE_PERSISTENT_ACLS: FALSE FILE_FILE_COMPRESSION : FALSE FILE_VOLUME_QUOTAS : TRUE FILE_SUPPORTS_SPARSE_FILES : FALSE FILE_SUPPORTS_REPARSE_POINTS: TRUE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: FALSE FILE_SUPPORTS_ENCRYPTION: FALSE FILE_NAMED_STREAMS : FALSE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE Thanks. The rest of your questions I will answer as soon as the new snapshot is available. 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. I'll try the new snapshot anyway. Franz. -- 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: rm -rf cannot delete the upmost directory level anymore on a Novell share
Am 2011-10-20 11:20, schrieb Corinna Vinschen: On Oct 19 18:43, Franz Sirl wrote: Am 2011-10-19 17:45, schrieb Corinna Vinschen: On Oct 19 17:12, Franz Sirl wrote: sometime between coreutils-7.0 and coreutils-8.4 (sorry, I don't have any other in between versions anymore) this simple command started to fail: # mkdir -p lev1/lev2/lev3 # rm -rfv lev1 removed directory: `lev1/lev2/lev3' removed directory: `lev1/lev2' rm: cannot remove `lev1': Device or resource busy Tested with coreutils-8.10 and cygwin1.dll from the 20111017 snapshot, as the cygwin1.dll didn't make any difference for the problem. If I just use rm.exe from coreutils-7.0 everything starts to work as expected again: # mkdir -p lev1/lev2/lev3 # rm -rfv lev1 removed directory: `lev1/lev2/lev3' removed directory: `lev1/lev2' removed directory: `lev1' The problem is, it works fine on local and remote NTFS, as well as on Samba. Since the number of open handles doesn't depend on the underlying filesystem, why should it fail for NWFS? True. But on the other hand NWFS and NcFsd exercise a lot of pathes in the Cygwin sourcecode that aren't usually used. Not really a lot. NWFS is known to have three problems: - The NtQueryInformationFile(FileBasicInformation) call fails. This call is only used in circumstance which don't affect NWFS. I think that still fails with NcFsd, I'll check it. - 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". - 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). Even between NWFS on XP and NcFsd on Win7 there are differences, because fs.is_nwfs() doesn't trigger on Win7 with the Novell Client (the filesystem name is different). I don't have access to the various filesystems, so I depend on users giving me the required information about exotic filesystems if they wish that it will be supported. For "NcFsd", can you please post the output of the `/usr/lib/csih/getVolInfo' command? Also, if you haven't already done so, plase create a Cygwin mount point pointing to some path on the filesystems and paste the output of the command `mount'. This shows under which filesystem NcFsd is subsumed right now. $ mount C:/cygwin/bin on /usr/bin type ntfs (binary,auto) C:/cygwin/lib on /usr/lib type ntfs (binary,auto) C:/cygwin on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) E: on /cygdrive/e type vfat (binary,posix=0,user,noumount,auto) F: on /cygdrive/f type ncfsd (binary,posix=0,user,noumount,auto) G: on /cygdrive/g type ncfsd (binary,posix=0,user,noumount,auto) H: on /cygdrive/h type ncfsd (binary,posix=0,user,noumount,auto) I: on /cygdrive/i type ncfsd (binary,posix=0,user,noumount,auto) J: on /cygdrive/j type ncfsd (binary,posix=0,user,noumount,auto) K: on /cygdrive/k type ntfs (binary,posix=0,user,noumount,auto) L: on /cygdrive/l type ncfsd (binary,posix=0,user,noumount,auto) N: on /cygdrive/n type smbfs (binary,posix=0,user,noumount,auto) T: on /cygdrive/t type ncfsd (binary,posix=0,user,noumount,auto) $ /usr/lib/csih/getVolInfo /cygdrive/j Device Type: 7 Characteristics: 30 Volume Name: Serial Number : 1549160268 Max Filenamelength : 255 Filesystemname : Flags : a2 FILE_CASE_SENSITIVE_SEARCH : FALSE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: FALSE FILE_PERSISTENT_ACLS: FALSE FILE_FILE_COMPRESSION : FALSE FILE_VOLUME_QUOTAS : TRUE FILE_SUPPORTS_SPARSE_FILES : FALSE FILE_SUPPORTS_REPARSE_POINTS: TRUE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: FALSE FILE_SUPPORTS_ENCRYPTION: FALSE FILE_NAMED_STREAMS : FALSE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE The rest of your questions I will answer as soon as the new snapshot is available. Franz. -- 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: rm -rf cannot delete the upmost directory level anymore on a Novell share
Am 2011-10-19 17:45, schrieb Corinna Vinschen: On Oct 19 17:12, Franz Sirl wrote: Hi, sometime between coreutils-7.0 and coreutils-8.4 (sorry, I don't have any other in between versions anymore) this simple command started to fail: # mkdir -p lev1/lev2/lev3 # rm -rfv lev1 removed directory: `lev1/lev2/lev3' removed directory: `lev1/lev2' rm: cannot remove `lev1': Device or resource busy Tested with coreutils-8.10 and cygwin1.dll from the 20111017 snapshot, as the cygwin1.dll didn't make any difference for the problem. If I just use rm.exe from coreutils-7.0 everything starts to work as expected again: # mkdir -p lev1/lev2/lev3 # rm -rfv lev1 removed directory: `lev1/lev2/lev3' removed directory: `lev1/lev2' removed directory: `lev1' The problem is, it works fine on local and remote NTFS, as well as on Samba. Since the number of open handles doesn't depend on the underlying filesystem, why should it fail for NWFS? True. But on the other hand NWFS and NcFsd exercise a lot of pathes in the Cygwin sourcecode that aren't usually used. Even between NWFS on XP and NcFsd on Win7 there are differences, because fs.is_nwfs() doesn't trigger on Win7 with the Novell Client (the filesystem name is different). If it turns out to be a problem in the Novell Client, I can work with Novell to fix it (for the Vista/Win7 client), but right now I'm not sure who's problem it is. Looking at the strace output of both rm-7.0 and rm-8.10 it seems that rm-8.10 thinks that lev1 is a file, because it uses unlink_nt() first. unlink_nt is used by unlink as well as by rmdir since the system calls to delete a file are the same as the calls to delete a directory. I see. 216 174576 [main] rm-8.10 336 unlink_nt: Opening file for delete failed, status = 0xC043 240 174816 [main] rm-8.10 336 seterrno_from_nt_status: /netrel/src/cygwin-snapshot-20111017-1/winsup/cygwin/fhandler_disk_file.cc:1735 status 0xC043 -> windows error 32 That's a sharing violation. Where's the difference to the strace output with the exact same Cygwin DLL and rm from coreutils 7? Hmm, I just see that on Win7 the errorcode for unlink_nt is different, for completeness: ... 2046 158907 [main] rm-8.10 2940 unlink_nt: Setting delete disposition failed, status = 0xC121 594 159501 [main] rm-8.10 2940 seterrno_from_nt_status: /netrel/src/cygwin-snapshot-20111017-1/winsup/cygwin/fhandler_disk_file.cc:1735 status 0xC121 -> windows error 5 193 159694 [main] rm-8.10 2940 geterrno_from_win_error: windows error 5 == errno 13 283 159977 [main] rm-8.10 2940 rmdir: -1 = rmdir (/test_rm_rf/lev1) ... The strace from rm-7.0 on XP looks like this: ... 3998 159342 [main] rm-7.0 360 rmdir: 0 = rmdir (/test_rm_rf/lev1/lev2/lev3) 435 159777 [main] rm-7.0 360 fhandler_base::set_close_on_exec: set close_on_exec for /test_rm_rf/lev1/lev2 to 1 225 160002 [main] rm-7.0 360 fhandler_disk_file::opendir: 0x20044A20 = opendir (/test_rm_rf/lev1/lev2) 272 160274 [main] rm-7.0 360 fhandler_base::fstat_helper: 0 = fstat (\??\J:\FRA\test_rm_rf\lev1\lev2, 0x22C7D0) st_size=0, st_mode=0x41ED, st_ino=-5551660102295404609st_atim=0.0 st_ctim=4E9EE2B4.0 st_mtim=4E9EE2B4.0 st_birthtim=4E9EE2B4.0 258 160532 [main] rm-7.0 360 fstat64: 0 = fstat (4, 0x22C7D0) 788 161320 [main] rm-7.0 360 fhandler_disk_file::readdir: 0 = readdir (0x20044A20, 0x22C704) (L"." > ".") (attr 0x10 > type 4) 146 161466 [main] rm-7.0 360 fhandler_disk_file::readdir: 0 = readdir (0x20044A20, 0x22C704) (L".." > "..") (attr 0x10 > type 4) 265 161731 [main] rm-7.0 360 normalize_posix_path: src /test_rm_rf/lev1/lev2/.. 132 161863 [main] rm-7.0 360 normalize_posix_path: /test_rm_rf/lev1/ = normalize_posix_path (/test_rm_rf/lev1/lev2/..) 266 162129 [main] rm-7.0 360 mount_info::conv_to_win32_path: conv_to_win32_path (/test_rm_rf/lev1) 134 162263 [main] rm-7.0 360 set_flags: flags: binary (0x2) 266 162529 [main] rm-7.0 360 mount_info::conv_to_win32_path: src_path /test_rm_rf/lev1, dst J:\FRA\test_rm_rf\lev1, flags 0x3000A, rc 0 198 162727 [main] rm-7.0 360 symlink_info::check: 0x0 = NtCreateFile (\??\J:\FRA\test_rm_rf\lev1) 214 162941 [main] rm-7.0 360 symlink_info::check: not a symlink 254 163195 [main] rm-7.0 360 symlink_info::check: 0 = symlink.check (J:\FRA\test_rm_rf\lev1, 0x22B350) (0x43000A) 266 163461 [main] rm-7.0 360 path_conv::check: this->path(J:\FRA\test_rm_rf\lev1), has_acls(0) 290 163751 [main] rm-7.0 360 geterrno_from_win_error: windows error 18 == errno 89 243 163994 [main] rm-7.0 360 fhandler_disk_file::readdir: 89 = readdir (0x20044A20, 0x22C704) (L"(null)" > "***") (attr 0x0 > type 0) 269 164263 [main] rm-7.0 360 fcntl64: 1 = fcntl (4, 1, 0x8) 295 164558 [main] rm-7.0 360 open: open (/test_rm_rf/lev1/lev2/.
rm -rf cannot delete the upmost directory level anymore on a Novell share
Hi, sometime between coreutils-7.0 and coreutils-8.4 (sorry, I don't have any other in between versions anymore) this simple command started to fail: # mkdir -p lev1/lev2/lev3 # rm -rfv lev1 removed directory: `lev1/lev2/lev3' removed directory: `lev1/lev2' rm: cannot remove `lev1': Device or resource busy Tested with coreutils-8.10 and cygwin1.dll from the 20111017 snapshot, as the cygwin1.dll didn't make any difference for the problem. If I just use rm.exe from coreutils-7.0 everything starts to work as expected again: # mkdir -p lev1/lev2/lev3 # rm -rfv lev1 removed directory: `lev1/lev2/lev3' removed directory: `lev1/lev2' removed directory: `lev1' Looking at the strace output of both rm-7.0 and rm-8.10 it seems that rm-8.10 thinks that lev1 is a file, because it uses unlink_nt() first. ... 3866 164248 [main] rm-8.10 336 rmdir: 0 = rmdir (/test_rm_rf/lev1/lev2/lev3) 295 164543 [main] rm-8.10 336 close: close (5) 231 164774 [main] rm-8.10 336 fhandler_base::close: closing '/test_rm_rf/lev1/lev2' handle 0x6FC 150 164924 [main] rm-8.10 336 close: 0 = close (5) 252 165176 [main] rm-8.10 336 normalize_posix_path: src /test_rm_rf/lev1/lev2 128 165304 [main] rm-8.10 336 normalize_posix_path: /test_rm_rf/lev1/lev2 = normalize_posix_path (/test_rm_rf/lev1/lev2) 267 165571 [main] rm-8.10 336 mount_info::conv_to_win32_path: conv_to_win32_path (/test_rm_rf/lev1/lev2) 133 165704 [main] rm-8.10 336 set_flags: flags: binary (0x2) 266 165970 [main] rm-8.10 336 mount_info::conv_to_win32_path: src_path /test_rm_rf/lev1/lev2, dst J:\FRA\test_rm_rf\lev1\lev2, flags 0x3000A, rc 0 333 166303 [main] rm-8.10 336 symlink_info::check: 0x0 = NtCreateFile (\??\J:\FRA\test_rm_rf\lev1\lev2) 345 166648 [main] rm-8.10 336 symlink_info::check: not a symlink 402 167050 [main] rm-8.10 336 symlink_info::check: 0 = symlink.check (J:\FRA\test_rm_rf\lev1\lev2, 0x22B5D0) (0x3000A) 252 167302 [main] rm-8.10 336 path_conv::check: this->path(J:\FRA\test_rm_rf\lev1\lev2), has_acls(0) 270 167572 [main] rm-8.10 336 build_fh_pc: fh 0x61256C7C, dev 0xC3 3861 171433 [main] rm-8.10 336 rmdir: 0 = rmdir (/test_rm_rf/lev1/lev2) 167 171600 [main] rm-8.10 336 normalize_posix_path: src /test_rm_rf/lev1 229 171829 [main] rm-8.10 336 normalize_posix_path: /test_rm_rf/lev1 = normalize_posix_path (/test_rm_rf/lev1) 398 172227 [main] rm-8.10 336 mount_info::conv_to_win32_path: conv_to_win32_path (/test_rm_rf/lev1) 399 172626 [main] rm-8.10 336 set_flags: flags: binary (0x2) 133 172759 [main] rm-8.10 336 mount_info::conv_to_win32_path: src_path /test_rm_rf/lev1, dst J:\FRA\test_rm_rf\lev1, flags 0x3000A, rc 0 318 173077 [main] rm-8.10 336 symlink_info::check: 0x0 = NtCreateFile (\??\J:\FRA\test_rm_rf\lev1) 227 173304 [main] rm-8.10 336 symlink_info::check: not a symlink 268 173572 [main] rm-8.10 336 symlink_info::check: 0 = symlink.check (J:\FRA\test_rm_rf\lev1, 0x22B5D0) (0x3000A) 253 173825 [main] rm-8.10 336 path_conv::check: this->path(J:\FRA\test_rm_rf\lev1), has_acls(0) 535 174360 [main] rm-8.10 336 build_fh_pc: fh 0x61256C7C, dev 0xC3 216 174576 [main] rm-8.10 336 unlink_nt: Opening file for delete failed, status = 0xC043 240 174816 [main] rm-8.10 336 seterrno_from_nt_status: /netrel/src/cygwin-snapshot-20111017-1/winsup/cygwin/fhandler_disk_file.cc:1735 status 0xC043 -> windows error 32 210 175026 [main] rm-8.10 336 geterrno_from_win_error: windows error 32 == errno 16 263 175289 [main] rm-8.10 336 rmdir: -1 = rmdir (/test_rm_rf/lev1) ... This happens both on XPSP3 (NWFS, Novell Client 4.91SP5IR1) and Win7SP1 (NcFsd, NovellClient2 SP1 IR9a). The strace was done on XP. Does this ring a bell for anyone? What else can I do to track down the cause? It cannot be so simple like rm-8.10 forgetting to close the open FDs of lev1 before trying to delete it? That was the only thing that jumped to my eyes while looking at the strace. Franz Sirl -- 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
