Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ofDirectory::createDirectory recursive gives an unnecessary warning #4258

Closed
ofZach opened this issue Aug 16, 2015 · 5 comments
Closed

ofDirectory::createDirectory recursive gives an unnecessary warning #4258

ofZach opened this issue Aug 16, 2015 · 5 comments

Comments

@ofZach
Copy link
Contributor

ofZach commented Aug 16, 2015

In trying to remove all the warnings from the project generator, I noticed that when using ofDirectory::createDirectory recursively it works yet throws a warning that the folder exists. for example, I am trying to create "/temp/test" at the desktop (ie, a nested folder):

if (ofDirectory::doesDirectoryExist("/Users/zachlieberman/Desktop/temp/test/")){
    cout << "there is a directory at this location " << endl;
} else {
    cout << "there is not a directory at this location " << endl;
}

ofDirectory::createDirectory("/Users/zachlieberman/Desktop/temp/test/", false, true);

gives back (if that folder isn't there)

there is not a directory at this location 
[warning] ofDirectory: createDirectory(): directory already exists: "/Users/zachlieberman/Desktop/temp/test/"

looking at the desktop, those nested folders are there.

it seems like an issue with the "create_directories" function used internally, since those directories are being generated but it's returning false instead of true.

@arturoc
Copy link
Member

arturoc commented Aug 16, 2015

i've been testing this and it's working for me fine without the warning. i've this PR: #4259 which adds tests, by now to the filesystem parts of OF, and even on osx everything passes fine. i've created a specific test for this but can't get it to fail.

you can see the results here:

https://travis-ci.org/openframeworks/openFrameworks/jobs/75816086

at the end of that there's the results from the unit tests.

perhaps you can use that test app to figure out a case in which it goes wrong?

i can merge it into master if that makes it easier

@ofZach
Copy link
Contributor Author

ofZach commented Aug 16, 2015

the function call is working (so it's making the folder) which might means it passes the test but there's a spurious warning (since create_directories is returning false, even though it is creating directories).

I tried it locally to the data path (as your test) but I still see the warning:

 there is not a directory at this location 
 [warning] ofDirectory: createDirectory(): directory already exists: "../../../data/temp/test/"

anyway, it's something that we can code around in "createDirectory" but flagging it if it's a symptom of something larger. I think an easy fix is to check if the directory exists before the operation (ofDirectory::createDirectory) and not use the success value to warn on.

@arturoc
Copy link
Member

arturoc commented Aug 16, 2015

yes, but i don't get the warning either in the tests and if i create the directory it's detecting it correctly and warning so not sure what might be going on

@ofZach
Copy link
Contributor Author

ofZach commented Aug 16, 2015

ok so digging into this abit more, I wonder if createDirectories returns false if any of the directories in the path already exist -- on OSX, if I comment out ofToDataPath() which adds ../../../data/ I start seeing success as true (ie, it's creating paths inside the bundle near the actual executable) but with ../../../data/ before paths I see success as false even if the final directory is made.... I'm not 100% sure about this, just a theory.

@arturoc
Copy link
Member

arturoc commented Aug 16, 2015

that's really strange, even calling ofToDataPath with and without absolute paths it's working without warnings in the tests:

https://github.com/openframeworks/openFrameworks/pull/4259/files#diff-86262fc52b8f00f5926afc5ed75ab4adR114

i've done other fixes in that branch and although i don't think they are related it might have fixed, i'm going to merge it so you can check if it still happens with those changes

@arturoc arturoc closed this as completed Aug 18, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants