[Tcl-bugs] [ tcl-Bugs-1951574 ] problem with "file executable" on windows, tcl 8.5.2

[SourceForge.net <no...@so...>]

Bugs item #1951574, was opened at 2008-04-25 14:26
Message generated for change (Comment added) made by ferrieux
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1951574&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. File System
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ralf Fassel (ralfixx)
Assigned to: Vince Darley (vincentdarley)
Summary: problem with "file executable" on windows, tcl 8.5.2

Initial Comment:
ActiveState TCL 8.5.2, Windows XP SP2

'file executable' always returns 0, even on .exe and .bat when asked
for a file on a network share:

    % info patchlevel
    8.5.2

    % set file L:/ralf/si++aegis/si++.4.0.C443/bin/winnt/gen.exe
    L:/ralf/si++aegis/si++.4.0.C443/bin/winnt/gen.exe
    % file exists $file
    1
    % file readable $file
    1
    % file executable $file
    0


% file stat l:/ralf/si++aegis/si++.4.0.C443/bin/winnt/gen.exe stat
% parray stat
stat(atime) = 1209122103
stat(ctime) = 1209068036
stat(dev)   = 11
stat(gid)   = 0
stat(ino)   = 65447
stat(mode)  = 33252
stat(mtime) = 1209068036
stat(nlink) = 1
stat(size)  = 143360
stat(type)  = file
stat(uid)   = 0
% file attributes l:/ralf/si++aegis/si++.4.0.C443/bin/winnt/gen.exe
-archive 0 -hidden 0 -longname L:/ralf/si++aegis/si++.4.0.C443/bin/winnt/gen.exe
 -readonly 0 -shortname L:/ralf/SWN7X3~G/SA8C5U~X/bin/winnt/gen.exe -system 0

The L:/ Network Share is an Samba share mounted from a linux box.


However, when copying the files to local disk, the files are qualified
as executable:

    % cp L:/ralf/si++aegis/si++.4.0.C443/bin/winnt/gen.exe d:/temp
    % file executable d:/temp/gen.exe
    1

% file stat d:/temp/gen.exe stat
% parray stat
stat(atime) = 1209124275
stat(ctime) = 1209064504
stat(dev)   = 3
stat(gid)   = 0
stat(ino)   = 52961
stat(mode)  = 33252
stat(mtime) = 1209064504
stat(nlink) = 1
stat(size)  = 143360
stat(type)  = file
stat(uid)   = 0


% file attributes  d:/temp/gen.exe
-archive 0 -hidden 0 -longname D:/temp/gen.exe -readonly 0 -shortname
D:/temp/gen.exe -system 0

=============================

In a debugging session I see that the problem is in tclwinfile.c, in NativeAccess(), #1702

	if (!(*tclWinProcs->accessCheckProc)(sdPtr, hToken, desiredAccess,
		&genMap, &privSet, &privSetSize, &grantedAccess,
		&accessYesNo)) {

This maps to the Windows-API AccessCheck() libary function and returns 0 in accessYesNo for the network file and 1 for the local file.

This currently is a real showstopper for us, so I'd appreciate any help...

This also happens in 8.4.x, but not in 8.3.x which does not have the extended security-descriptor checks.

Note that the file-stat-mode is the same for the network and local file and seems to include owner-execute-permissions for both files.


Thanks
R'





----------------------------------------------------------------------

>Comment By: Alexandre Ferrieux (ferrieux)
Date: 2008-04-25 15:51

Message:
Logged In: YES 
user_id=496139
Originator: NO

The semantic mismatch between Unix and Windows file permissions is
profound, and Samba cannot be entirely blamed. Moreover, you discovered
that the Win32 function responsible for this check did exhibit the problem.
Then, I'd requalify this not as a Tcl bug, but rather an feature request to
work around an OS/Samba bug.

Moreover, I wonder why somebody would be interested in the executable flag
on Windows, where the extension .EXE .BAT (or whatever in PATHEXT) is, to
my knowledge, the only criterion used by the OS itself to decide whether it
should execute it or not. Am I right to believe this, in which case the
thing to do would be to add an extension check in [file executable], or is
there really an OS-enforced executable flag in some flavours of Windows, in
which case the OS/Samba route is worth pursuing ?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1951574&group_id=10894