bugmake - Bugs: bug #26075, $(wildcard) function holds parent...

 
 

bug #26075: $(wildcard) function holds parent directories open preventing deletes

Submitted by:  Peter Halliday <centraspike>
Submitted on:  Fri 03 Apr 2009 09:33:42 AM UTC  
Votes:  1  
 
Severity: 3 - NormalItem Group: Bug
Status: Works for mePrivacy: Public
Assigned to: NoneOpen/Closed: Closed
Component Version: 3.81Operating System: MS Windows
Fixed Release: 4.0Triage Status: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Mon 21 Oct 2013 08:43:36 AM UTC, comment #7:

I cannot reproduce this with Make 4.0 compiled with MinGW. Not only don't I see the error message, I also see closedir being called for each opendir.

So either the problem was fixed (perhaps inside glob.c, when it was updated from upstream), or something else is required to reproduce the problem.

I'm closing the bug; feel free to reopen if new data is available that allows to reproduce this.

Eli Zaretskii <eliz>
Project Member
Sat 04 Apr 2009 01:11:28 AM UTC, comment #6:

Couldn't find the data but the "dir-.c" I was using to get them. Attached without any warranty. Use instead of dir.c.

(file #17863)

Anonymous
Sat 04 Apr 2009 12:10:09 AM UTC, comment #5:

Hm, that's interesting. There's no doubt that the directory cache causes unexpected consequences when your makefile does things "behind the scenes" that make doesn't know about (so it can't update the cache appropriately).

However, this is the first time I've ever heard the assertion that it is actually slower than no cache at any time, much less on average, or by magnitudes.

I'm not saying you're wrong, because I've never tested it myself. But, do you have any hard data to prove this assertion?

Paul D. Smith <psmith>
Project Administrator
Fri 03 Apr 2009 11:58:36 PM UTC, comment #4:

Actually that directory cache is just crap. Not only that it causes several bad sideeffects (like new files not being noticed) but actually is slower on average than no cache at all, in cases slowser by magnitudes.

Anonymous
Fri 03 Apr 2009 09:21:30 PM UTC, comment #3:

If you use "strace" you will see the same problem on Ubuntu - but you won't see "rm" throw an error because the Linux file system you are using allows directories to be unlinked even if they are in use.

This is still a bug, though, even though it isn't obvious on some systems.

Anonymous
Fri 03 Apr 2009 01:28:35 PM UTC, comment #2:

I think I have a fix for this issue (at least it's working for me with my makefiles). I have edited dir.c to limit the maximum number of open directories under windows to just 1 (normally it is 10) this results in directories being closed straight away after caching contents. The change is to replace the following line:

with:

I have also attached my version of dir.c

(file #17859)

Peter Halliday <centraspike>
Fri 03 Apr 2009 09:43:02 AM UTC, comment #1:

I've just tried the same construct on Ubuntu where it works just fine so it does seems to be windows specific. I'm currently digging through the source to see if i've forgotten to set some flag at compile time or if i can see the error but so far i haven't found anything.

Peter Halliday <centraspike>
Fri 03 Apr 2009 09:33:42 AM UTC, original submission:

Apologies for the windows stuff but the following makefile clean target does not work:

all: $(filter-out $(wildcard build\release), build\release)

build\release:
mkdir build\release

clean:
rmdir /Q /S build

First do gmake all then try gmake clean. The following error occurs:

rmdir /Q /S build
The process cannot access the file because it is being used by another process.
gmake: *** [clean] Error 32

I have managed to trace the cause to the fact that the wildcard function opens a handle to the build directory in order to check if the release directory exists and then does not release the handle till gmake exits

Peter Halliday <centraspike>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #17863:  dir-.c added by None (5KiB - text/plain - dir.c w/o cache (for testing purposes))
file #17859:  dir.c added by centraspike (31KiB - text/plain - Modified dir.c to prevent directory locks on windows)
file #17857:  makefile added by centraspike (131B - application/octet-stream - Example makefile)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by eliz (Posted a comment)
  • -unavailable- added by jbezem (Voted in favor of this item)
  • -unavailable- added by psmith (Posted a comment)
  • -unavailable- added by centraspike (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 1 encouragement so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 21 Oct 2013 08:43:36 AM UTCelizStatusNone=>Works for me
      Open/ClosedOpen=>Closed
      Fixed ReleaseNone=>4.0
    Thu 16 Apr 2009 06:21:30 AM UTCjbezemCarbon-Copy-=>Added jbezem
    Sat 04 Apr 2009 01:11:28 AM UTCNoneAttached File-=>Added dir-.c, #17863
    Fri 03 Apr 2009 01:28:35 PM UTCcentraspikeAttached File-=>Added dir.c, #17859
    Fri 03 Apr 2009 09:33:42 AM UTCcentraspikeAttached File-=>Added makefile, #17857

    Back to the top


    Powered by Savane 3.1-cleanup1