Tcl Source Code

View Ticket
Login
Ticket UUID: 928545
Title: OSX: force rename
Type: Bug Version: obsolete: 8.4.6
Submitter: tauvan Created on: 2004-04-02 21:19:54
Subsystem: 37. File System Assigned To: vincentdarley
Priority: 5 Medium Severity:
Status: Closed Last Modified: 2006-04-05 09:20:25
Resolution: Out of Date Closed By: sf-robot
    Closed on: 2006-04-05 02:20:25
Description:
int 
TclpObjRenameFile(srcPathPtr, destPathPtr)
    Tcl_Obj *srcPathPtr;
    Tcl_Obj *destPathPtr;
{
    int retVal = DoRenameFile(Tcl_FSGetNativePath(srcPathPtr), 
                              Tcl_FSGetNativePath(destPathPtr));
    if (errno == EISDIR) {
        Tcl_Obj *errorBuffer = NULL;
        retVal = TclpObjRemoveDirectory(destPathPtr, FALSE, &
errorBuffer);
        if (retVal) {
            return retVal;
        }
        retVal = TclpObjCopyDirectory(srcPathPtr, destPathPtr, &
errorBuffer);
        retVal = TclpObjRemoveDirectory(srcPathPtr, TRUE, &
errorBuffer);
    }
    return retVal;
}
User Comments: sf-robot added on 2006-04-05 09:20:24:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

das added on 2006-03-21 19:24:38:
Logged In: YES 
user_id=90580

no longer see this test failure on HEAD, presumably this report is out of date ?
having some trouble following what this was about in the first place...

tauvan added on 2004-05-07 00:54:36:

File Added - 86308: c84b_rename.patch

tauvan added on 2004-05-07 00:54:35:
Logged In: YES 
user_id=1011552

 The reason for the extra Apple mess, appears that Apple's
early import of rename() handled errno differently than 10.3,
I could not find Apple's source code to verify this.
  The patch attached also includes some new tests, one which looks
like it points out a bug. I didn't correct for it as this is
what the old code does. And please don't laugh at my shody script
code, I'm only learning to just do it.
  The patch is for core-8-4-branch.
  Also, it assumes that Tcl_FSGetNativePath strips trailing '/' as it
looked like an early SunOS issue.

tauvan added on 2004-04-08 00:01:44:
Logged In: YES 
user_id=1011552

Hi, still here.
 I was trying to gather more debug info and I have a
question. As stated previously, this occurs as local and does not 
occur as Root.
 If you look at bug #910323, the only way I can get to SHLVL=3
is login as root then run "sh". For me LOGNAME=root, for Jonathan
LOGNAME=jleffler. I assume he is still running as local and not
root.
 Note that his report does not include the fCmd fails. So I'm trying
to duplicate a simular enviroment, ie.. SHLVL=3, LOGNAME=steven.
Any ideas??? and is that a MAC OSX 10.3 specific generated report?

Thanks.

tauvan added on 2004-04-05 09:54:55:
Logged In: YES 
user_id=1011552

As I recall, when DoRenameFile returns OK, there is no errno,
and this EISDIR check was placed here so that the inital tests
took precendence. As far as the leak, don't know, I'm an idiot!
These were my found solutions.

PS I started over from scratch  to try and provide more detailed
info. So if I forget something or need why I do something stupid,
Steven J Abner
[email protected]

vincentdarley added on 2004-04-05 06:17:12:
Logged In: YES 
user_id=32170

Looking at the comments to TclpObjRenameFile, I see this:

 *If the directory was successfully created, returns TCL_OK.
 *Otherwise the return value is TCL_ERROR and errno is set to
 *indicate the error.  Some possible values for errno are:
 *
[snip]
 *EISDIR:    dst is a directory, but src is not.

This suggests that the blanket treatment of 'EISDIR' by an
attempt to delete the directory and then fallback on
copy/rename is likely to introduce new bugs.

Another issue is that your patch doesn't check 'retVal !=
TCL_OK' before examining errno, which is likely to be wrong.

Finally, another issue is that your patch undoubtedly leaks
a Tcl_Obj in 'errorBuffer'.  I think a better place to patch
would be inside DoRenameFile.  

However, overall it seems we need to understand why the OS's
"rename(src,dst)" is failing.  Reassigning to someone with
more understanding of OSX for help.

tauvan added on 2004-04-03 22:55:29:
Logged In: YES 
user_id=1011552

Well I duplicated the errors, just removed the code.

First:
  machine: mac ppc G4 (1st PCI 400Mhz) OSX 10.1.5
 
The errors occured running the test as local user,
as root no errors.
No other errors but the fCmd.test.

Summaries:
---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: error renaming "td2" to "td1/td2": illegal operation on a 
directory
    while executing
"file rename -force td2 td1"
    ("uplevel" body line 6)
    invoked from within
"uplevel 1 $script"
---- errorCode: POSIX EISDIR {illegal operation on a directory}
==== fCmd-6.15 FAILED

---- Result was:
1 {error renaming "td2" to "td1/td2": illegal operation on a directory}
---- Result should have been (exact matching):
1 {error renaming "td2" to "td1/td2": file already exists}
==== fCmd-6.16 FAILED

---- Result was:
1 {error renaming "td2" to "td1/td2": illegal operation on a directory}
---- Result should have been (exact matching):
1 {error renaming "td2" to "td1/td2": file already exists}
==== fCmd-6.18 FAILED

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: error renaming "tds1" to "tdd1/tds1": illegal operation 
on a directory
    while executing
"file rename -force tds1 tdd1"
    ("uplevel" body line 25)
    invoked from within
"uplevel 1 $script"
---- errorCode: POSIX EISDIR {illegal operation on a directory}
==== fCmd-9.8 FAILED

---- Result was:
{tdd1 tdd2 tds1 tds2} {1 {error renaming "tds1" to "tdd1/tds1": illegal 
operation on a directory}} {1 {error renaming "tds2" to "tdd2/tds2": 
illegal operation on a directory}} 1 0
---- Result should have been (exact matching):
{tdd1 tdd2 tds1 tds2} {1 {error renaming "tds1" to "tdd1/tds1": file 
already exists}} {1 {error renaming "tds2" to "tdd2/tds2": file already 
exists}} 1 0
==== fCmd-9.9 FAILED

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: error renaming "td3" to "td4/td3": illegal operation on a 
directory
    while executing
"file rename -force td3 td4"
    ("uplevel" body line 8)
    invoked from within
"uplevel 1 $script"
---- errorCode: POSIX EISDIR {illegal operation on a directory}
==== fCmd-9.12 FAILED

---- Result was:
1 {error renaming "td1" to "td2/td1": illegal operation on a directory}
---- Result should have been (exact matching):
1 {error renaming "td1" to "td2/td1": file already exists}
==== fCmd-9.13 FAILED

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: error renaming "tfa" to "tfad/tfa": illegal operation on a 
directory
    while executing
"file rename -force tfa tfad"
    ("uplevel" body line 4)
    invoked from within
"uplevel 1 $script"
---- errorCode: POSIX EISDIR {illegal operation on a directory}
==== fCmd-18.8 FAILED

If you need I can give you build settings. I'm still in development
state, but have Tcl currently running "all.tcl" with no errors.
The fail also occurs with or with other solution to fileSystem errors.

PS sorry I'm new at this reporting stuff. I've never tried to
report fixes just did them and be done. However, since Tcl seems
to be a corner stone, I thought I'd try.

vincentdarley added on 2004-04-03 17:55:50:
Logged In: YES 
user_id=32170

Can you please tell us what test suite errors this
corresponds to?  On my machine/os all fileSystem and fCmd
and fileName tests complete successfully.

To apply any such patch we need to (a) be able to
reproduce/understand the problem, and then (b) see that the
patch solves the problem in the right way, and (c) that it
doesn't introduce new problems.

Without much more detail on "the errors", we can't do any of
the above!

(The one test you cite is actually in fCmd.test, not
fileSystem.test, so that confuses the issue further).

Sorry not to be more positive/helpful, but when
reporting/fixing bugs I'm afraid you're going to have to be
more forthcoming (either that or send us your computer so we
can see for ourselves ;-)

Anyway, hopefully once you've supplied a lot more info, we
can resolve this one way or another.

tauvan added on 2004-04-03 11:24:22:
Logged In: YES 
user_id=1011552

This was code that solved the fileSystem.test errors.
Since I didn't write down the reason when I fixed it,
I believe it was the rename of directories that should have
succeeded but didn't. look at some old output:

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: error renaming "td2" to "td1/td2": illegal operation on a 
directory
    while executing
"file rename -force td2 td1"
    ("uplevel" body line 6)
    invoked from within
"uplevel 1 $script"
---- errorCode: POSIX EISDIR {illegal operation on a directory}
==== fCmd-6.15 FAILED

 and others. I'd have to go back to old code to try and duplicate

tauvan added on 2004-04-03 09:19:16:
Logged In: YES 
user_id=1011552

This was code that solved the fileSystem.test errors.
Since I didn't write down the reason when I fixed it,
I believe it was the rename of directories that should have
succeeded but didn't. look at some old output:

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: error renaming "td2" to "td1/td2": illegal operation on a 
directory
    while executing
"file rename -force td2 td1"
    ("uplevel" body line 6)
    invoked from within
"uplevel 1 $script"
---- errorCode: POSIX EISDIR {illegal operation on a directory}
==== fCmd-6.15 FAILED

 and others. I'd have to go back to old code to try and duplicate

vincentdarley added on 2004-04-03 05:18:34:
Logged In: YES 
user_id=32170

Would you mind attaching some explanation to this?  Is this
a bug report (what bug?) a feature request (for what
exactly?)....Are you saying the code doesn't agree with its
documentation?  Can you supply a test to demonstrate the issue?

Without any further info, this report is intriguing, but not
particularly useful...

Attachments: