From: SourceForge.net <no...@so...> - 2013-01-03 11:44:55
|
Bugs item #3092089, was opened at 2010-10-21 06:58 Message generated for change (Comment added) made by nijtmans You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3092089&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 36. Pathname Management Group: obsolete: 8.5.11 Status: Open Resolution: None Priority: 8 Private: No Submitted By: Mark Garvey (dunkfan) Assigned to: Don Porter (dgp) Summary: [file normalize] can remove path components Initial Comment: On MS Windows, [file normalize C:\\Test\\Dir1\\Dir2] will return only C:/Test/Dir1/ if the "List Folder Contents" ACL property is missing from Dir1. Likewise [file normalize C:\\Test\\Dir1\\Dir2\\Dir3] returns C:/Test/Dir1//Dir3 So even if a user has permission to access Dir2, using the normalized path of Dir2 is lethal. This particularly happens with "junction points". See http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/c52f1b16699139b7/e4b19f32bdcf0f9b?lnk=gst&q=file+normalize#e4b19f32bdcf0f9b ---------------------------------------------------------------------- >Comment By: Jan Nijtmans (nijtmans) Date: 2013-01-03 03:44 Message: Harald, please have a look at the "bug-3092089" branch. Does that work for you? Explanation: if GENERIC_READ doesn't work in some cases, and 0 doesn't work in other cases, why don't we just try both and pick the one that works? (I'm not even trying to understand what's going on here.......) Regards, Jan Nijtmans ---------------------------------------------------------------------- Comment By: Harald Oehlmann (oehhar) Date: 2012-12-13 01:47 Message: I have tried the patch proposed at this comment: Date: 2011-12-12 06:47:09 PST Sender: dunkfan with tcl8.5.13, msvc++ 6, Makefile.vc, win vista 32 bit. Here is the applied patch: --- C:/test/tcl8.5.13/win/tclWinFile_ori.c Tue Nov 06 16:05:00 2012 +++ C:/test/tcl8.5.13/win/tclWinFile.c Thu Dec 13 09:47:22 2012 @@ -704,7 +704,7 @@ HANDLE hFile; DWORD returnedLength; - hFile = (*tclWinProcs->createFileProc)(linkDirPath, GENERIC_READ, 0, + hFile = (*tclWinProcs->createFileProc)(linkDirPath, 0, 0, NULL, OPEN_EXISTING, FILE_FLAG_OPEN_REPARSE_POINT|FILE_FLAG_BACKUP_SEMANTICS, NULL); Results: 1) The issue is solved for me. The demonstration in comment Date: 2012-11-15 01:05:50 PST Sender: oehhar of tcl bug 3587096 now returns: % file normalize c:/test2_junction/tcl860rc0 C:/test2/tcl860rc0 % file normalize c:/test2_junction/tcl860rc0/bin C:/test2/tcl860rc0/bin % file normalize c:/test2_junction/tcl860rc0/bin/junk 2) Bug 3587096 is also solved 3) Many many tests fail in the test suite with "permission denied on file access" The test log is in the file section (200kB). Here the first failure as an example: ==== autoMkindex-4.1 platform indenpendant source commands FAILED ==== Contents of test case: file delete tclIndex auto_mkindex . pkg/samename.tcl set f [open tclIndex r] set dat [split [string trim [read $f]] "\n"] set len [llength $dat] set result [lsort [lrange $dat [expr {$len-2}] [expr {$len-1}]]] close $f set result ---- Test generated error; Return code was: 1 ---- Return code should have been one of: 0 2 ---- errorInfo: couldn't open "tclIndex": permission denied while executing "open "tclIndex" w" (procedure "auto_mkindex" line 32) invoked from within "auto_mkindex . pkg/samename.tcl" ("uplevel" body line 3) invoked from within "uplevel 1 $script" ---- errorCode: POSIX EACCES {permission denied} ==== autoMkindex-4.1 FAILED 3) In a practical test, the modified version worked well for me. Thank you, Harald ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2012-05-10 14:53 Message: Not new to 8.6; low user pressure. Not a release-blocker for 8.6 I guess => prio 8. ---------------------------------------------------------------------- Comment By: Mark Garvey (dunkfan) Date: 2011-12-22 03:18 Message: Sorry my patch fixes the junction problem C:/Documents and Settings, but not the latest C:/windows/system32/drivers/etc/hosts one. An explorer on my system does not show the C:/Documents and Settings folder, but it shows the C:/Windows/system32/drivers/etc folder. tk_chooseDirectory shows neither! Why the difference...? ---------------------------------------------------------------------- Comment By: Mark Garvey (dunkfan) Date: 2011-12-12 06:47 Message: Found the culprit: tclWinFile.c and the NativeReadReparse call. When I replace GENERIC_READ with 0, in the CreateFileProc and remake then: file normalize {C:\Documents and Settings\Guest} returns: C:\Users\Guest as expected, instead of the incorrect C:\Documents and Settings. cd and pwd also work correctly after crossing the Junction. :-) According to the MSDN using 0 implies theat the file is only queried and not accessed. That seems to cure it! Please patch! ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2011-11-17 12:49 Message: Is there a patch available to make Tcl's native filesystem support do the right thing? ---------------------------------------------------------------------- Comment By: juergen gohlke (juergen18) Date: 2011-11-17 09:08 Message: This bug is in fact a big problem and required me to write a work around in C to access the Microsoft API directly. I am using TCL/TK for an installer, and the typical target directories as seen in the Windows explorer contain at least one junction point, whose contents is not readable (this is the system default). E.g. C:\Programme\ on a German Windows is a junction point to C:\programs\. None of the proposals in the thread mentioned above actually helps. ---------------------------------------------------------------------- Comment By: Mark Garvey (dunkfan) Date: 2010-10-27 02:24 Message: No. I can reproduce this in 8.5.5 and 8.4.19. However, the problem is appearing more often as we are moving away from XP to Vista/Win7 Here is a snip from 8.4.19 running on Windows Vista Business 32 English % cd {C:/Documents and Settings} % cd Default % file normalize . C:/Documents and Settings % info patchlevel 8.4.19 % In a cmd I see the following entry for C:\Documents and Settings, this is causing the trouble dir /a c:\ 02/11/2006 15:02 <JUNCTION> Documents and Settings [C:\Users] One of the guys here had a go at solving the normalized problem with such paths having googled for an answer. I'm including a small prog that may be of use. Im not sure how it works or what it does but seeing the API calls used may be of help. A NULL arg to CreateFile helps get the job done. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2010-10-26 10:27 Message: Is this new (mis-)behavior in 8.5.9 ? Or a problem that has a longer history? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3092089&group_id=10894 |