Toolbox init-project fails when .ds-store is in the project folder

Enonic version: 6.1.0
OS: El Capitan

Usually when I try to use the toolbox init-project, it fails due to the project folder not being empty. But the only file in there is .ds-store. It works if I delete the .ds-store file immediately before running the, but it’s kind of a pain to do that every time.


This behaviour is wanted.
We do not want the init-project to write into a non empty directory

Oh, the punishment for not developing solely inside the command line! :confounded:

I’ll throw in a feature request:

toolbox init-project should ignore the following items (or have a -f forced flag) :
.DS_Store, .AppleDouble, .LSOverride, .AppleDB, .AppleDesktop, Thumbs.db, ethumbs.db, Desktop.ini, Icon, and similar system metadata files

1 Like

I like the forced flag proposition.
If it is validated, you can expect it for Enonic XP 6.2.0

How about ignoring any .* and #* files that may already exist there?

For the moment, the first step of Init-project is a git clone. (Actually the restriction “the folder cannot be existing and not empty” comes from git clone and not the tool).
So in our case it would overwrite the .git if there was one. But let’s say that it does it in a temporary folder and then just move the content without the git related files.

Now, if you have one of these files (.* and #* files) in your directory and in the starter kit. What should the tool do?
It should not overwrite without a warning to the user and should not skip these files.
And in general the tool should not keep a list of OS specific file names to be treated differently.

What you want, most of the time, is to create the project in a new folder
So in the documentation, rather than “ init-project -n -r starter-base"
It should say “ init-project -n -r starter-base -d myapp”.

It would create the project folder with inside the project content, which is what you want.

(But I still like the idea of a forced flag to not block the user)

overwriting any existing items is no problem at all…
I think we’re complicating things here.