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.

Sign up for GitHub

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

Jump to bottom

Name collisions are causing not all files to be copied #205

Closed
eliasdawson opened this issue May 9, 2012 · 4 comments
Closed

Name collisions are causing not all files to be copied #205

eliasdawson opened this issue May 9, 2012 · 4 comments
Assignees
@balupton
Labels
3 - closed - success affects core difficulty days type defect
Milestone
May

Comments

@eliasdawson
Copy link

I'm working on converting a site to use DocPad as an experiment and I've discovered that several files are silently ignored when generating. Some files of the same type are copied, but others are not. Problem extensions seem to be .svg, .ttf, .eot, and .otf. If there isn't some processing specified for a file, shouldn't it just be copied?
@balupton
Copy link
Member

balupton commented May 9, 2012

Hrmmm, those extensions should work. Can you provide me with access to the repository that you're working on, and I'll try and figure out what's going fishy.

If there isn't some processing specified for a file, shouldn't it just be copied?

For a little background, there are several patterns that DocPad should always ignore, the land of filesystems is very convoluted in this way. For instance certain operating systems and editors will often like to create several different types of cache files inside a directory that we always want to ignore. Also things like .svn folders we do not want to copy over, as they are specify to that path, and not the output path - will cause a corrupt svn repository. However, it doesn't seem like this would be related to this issue.

@eliasdawson
Copy link
Author

That makes a lot of sense., and I should say I really like DocPad. I've been experimenting with several Static Site Generators and it's my favorite so far.

I can't share the repository since it's for work, but I did some more testing, and I'm convinced it's actually a name collision. If I have multiple font or image files with the same name and different extensions, only one is copied. This issue didn't occur in previous versions when using the public directory.

I think it's related to #Num: #190, and I would cast a vote for going back to not processing the public directory. I think it's probably the case that there will always be some situation where a user would want some files ignored and copied verbatim. It's a good safety net and adds flexibility. For example it offers a work-around for Issue #Num: #192.

@ghost ghost assigned balupton May 15, 2012
@balupton balupton mentioned this issue May 15, 2012
Closed
@balupton
Copy link
Member

Name collision problem fixed in the just released 5.2.2.

balupton added a commit that referenced this issue May 17, 2012
@balupton
v5.2.2. Bug fixes.
588e40a 
- v5.2.2 May 17, 2012
	- Fixed [#208](#208) - Multiple
file extensions being trimmed
	- Fixed [#205](#205) - Name
collisions are causing not all files to be copied
	- Changed file `id` to default to the `relativePath` instead of the
`relativeBase`
	- Finding layouts now uses `id: $startsWith: layoutId` instead of `id:
layoutId`
@eliasdawson
Copy link
Author

Finally got back to this and it's working as expected. Thanks.

balupton added a commit that referenced this issue Oct 23, 2013
@balupton
Fixed #205 - Name collisions are causing not all files to be copied
69c1bf5
balupton added a commit that referenced this issue Oct 23, 2013
@balupton
v5.2.2. Bug fixes.
565c1f5 
- v5.2.2 May 17, 2012
	- Fixed [#208](#208) - Multiple
file extensions being trimmed
	- Fixed [#205](#205) - Name
collisions are causing not all files to be copied
	- Changed file `id` to default to the `relativePath` instead of the
`relativeBase`
	- Finding layouts now uses `id: $startsWith: layoutId` instead of `id:
layoutId`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@balupton balupton

Labels
3 - closed - success affects core difficulty days type defect
Projects
None yet
Milestone
May
Development

No branches or pull requests
2 participants
@balupton @eliasdawson