This fixes two things: The format detection, and a bug in `udif`.
First, by categorizing the `.dmg` extension as compressed image,
`.isSupportedImage()` would attempt to detect the format after stripping
the extension, causing it to be misdetected.
Second, `udif`'s ReadStream didn't add the `dataForkOffset` to its
position when reading blocks, causing the wrong data to be read for some images,
in turn causing zlib to error on invalid headers.
Changes:
- Classify `.dmg` as `type: 'image'`
- Update `udif` to 0.8.0
Change-Type: patch
Changelog-Entry: Fix Apple disk image detection & streaming
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
If the user tries to drag and drop a directory to the application, then
he'll get a scary `EISDIR` error message. This commit catches this
error, and display a nice user friendly message instead.
Change-Type: patch
Changelog-Entry: Prevent uncaught `EISDIR` when dropping a directory to the application.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
The `application/x-apple-diskimage` handler doesn't return a path,
causing an issue when fetching the image metadata, and trying using the
path to determine if its a supported image type.
Change-Type: patch
Changelog-Entry: Fix "Path must be a string. Received undefined" when selecting Apple images.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This is a regression caused by
https://github.com/resin-io/etcher/pull/1257, which introduced a new way
to detect mime types by using the `mime-types` module.
This module, contrary to `file-type`, will detect certain ISO files as
`application/x-iso9660-image`, which Etcher doesn't know how to handle,
and will therefore should at the user that the format is unsupported.
Change-Type: patch
Changelog-Entry: Don't interpret certain ISO images as unsupported.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
`image-stream` returns image objects that look like this:
```js
{
stream: <readable stream>,
transform: <transform stream>,
size: {
original: <number>,
final: {
value: <number>,
estimation: <boolean>
}
},
...
}
```
While the GUI handles image objects that look like this:
```sh
{
path: <string>,
size: <number>,
...
}
```
It looks like we should share a common structure between both, so we can
use `image-stream` images in `drive-constraints`, for example.
Turns out that we actually transform `image-stream` image objects to GUI
image objects when the user selects an image using the image selector
dialog, which is another indicator that we should normalise this
situation.
As a solution, this commit does the following:
- Add `path` to `image-stream` image object
- Reuse `image-stream` image objects in the GUI, given they are a
superset of GUI image objects
See: https://github.com/resin-io/etcher/pull/1223#discussion_r108165110
Fixes: https://github.com/resin-io/etcher/issues/1232
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
The dependency is not yet removed from `npm-shrinkwrap.json` given that
there another one that keeps requiring it.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
When fetching metadata, a stream is opened, but never consumed.
This destroys the stream when retrieving metadata to avoid
dangling open file descriptors and such.
Change-Type: patch
Changelog-Entry: Fix unmounting freezing in macOS.
Fixes: https://github.com/resin-io/etcher/issues/985
* chore: get the CI tests working again
* an updated eslint-plugin-lodash was creating extra linter errors where we
were using built-in String methods instead of the lodash equivalents
* an updated codespell package now installs with a different executable-name
(no .py extension), and now supports multiple dictionaries
* while I was at it I replaced the messy double-quoting-string logic with the
command-join module
Changelog-type: patch
* chore: downgrade codespell to 1.9.2 because the latest version has issues running on Windows
(we'll hopefully be able to revert this commit when codespell works again properly!)
The current error handling logic is a mess. We have code that tries to
fetch information about errors in different places throughout the
application, and its incredibly hard to ensure certain types of error
get decent human friendly error messages.
This commit groups, improves, and tests all error related functions in
`lib/shared/errors.js`.
Here's a summary of the changes, in more detail:
- Move the `HUMAN_FRIENDLY` object to `shared/errors.js`
- Extend `HUMAN_FRIENDLY` with error descriptions
- Add `ENOMEM` to `shared/errors.js`
- Group CLI and `OSDialogService` mechanisms for getting an error title
and an error description
- Move error serialisation routines from `robot` to `shared/errors.js`
- Create and use `createError()` and `createUserError()` utility
functions
- Add user friendly descriptions to many errors
- Don't report user errors to TrackJS
Fixes: https://github.com/resin-io/etcher/issues/1098
Change-Type: minor
Changelog-Entry: Make errors more user friendly throughout the application.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This is one step towards enforcing the linter until we barely have to
check for style issues on code reviews.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
There are a lot of new rules since the last time I revised the ESLint
rules documentation.
I've updated the main `.eslintrc.yml` to include some newer additions,
plus I added another ESLint configuration file inside `tests`, so we can
add some stricted rules to the production code while relaxing them for
the test suite (due to the fact that Mocha is not very ES6 friendly and
Angular tests require a bit of dark magic to setup).
This is a summary of the most important changes:
- Disallow "magic numbers"
These should now be extracted to constants, which forces us to think of
a good name for them, and thus make the code more self-documenting (I
had to Google up the meaning of some existing magic numbers, so I guess
this will be great for readability purposes).
- Require consistent `return` statements
Some functions relied on JavaScript relaxed casting mechanism to work,
which now have explicit return values. This flag also helped me detect
some promises that were not being returned, and therefore risked not
being caught by the exception handlers in case of errors.
- Disallow redefining function arguments
Immutability makes functions easier to reason about.
- Enforce JavaScript string templates instead of string concatenation
We were heavily mixing boths across the codebase.
There are some extra rules that I tweaked, however most of codebase
changes in this commit are related to the rules mentioned above.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
These errors happen when the user selects an archive that contains no
image, or multiple images, and represents a user error, rather than an
unhandled exception.
For this reason, we should not report this to TrackJS.
This means, however, that we need a reliable way to know whether an
error should be reporter or not. This commit implements
`AnalyticsService.shouldReportError()` for this purpose, which will
check an optional `report` property of the error object.
In order to ensure that errors that we don't control are reported, the
function will return `true` if the error object doesn't have that
property.
Change-Type: patch
Changelog-Entry: Don't report "invalid archive" errors to TrackJS.
Fixes: https://github.com/resin-io/etcher/issues/1103
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
We currently attempt to read extra metadata from ZIP files, such as a
logo, image name, image url, etc. In order to simplify the metadata
story, we decided that this metadata will not live on the image itself,
but rather on a centralised repo, which greatly simplified our custom
archive extraction logic and allows us to make use of these nice
features even when streaming the image directly from the internet.
We'll be working on bringing back this functionality from a centralised
repo in subsequent commits.
Change-Type: major
Changelog-Entry: Remove extended archives metadata extraction logic.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
The `image-stream` module currently returns a readable stream, a
transform stream, a "size", and an optional "estimatedUncompressedSize".
Based on this information, its hard to say what "size" represents. Some
format handlers return the compressed size and provide a decompression
transform stream while others return the decompressed stream directly
and put the decompressed size in "size".
As a way to simplify this, every format handler now returns a "size"
object with the following properties:
- `original`: The original compressed size
- `final.estimated`: Whether the final size is an estimation or not
- `final.value`: The final uncompressed size
As a bonus, we extract the file size retrieval logic to
`imageStream.getFromFilePath()`, which is the onlt part where the
concept of a file should be referred to.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This is a long lasting task. The `etcher-image-stream` project takes
care of converting any kind of image input into a NodeJS readable
stream, handling things like decompression in betwee, however its a
module that, except for weird cases, there is no benefit on having
separate from the main repository.
In order to validate the assumption above, we've left the module
separate for almost a year, and no use case has emerged to keep it
like that.
This commit joins the code and tests of that module in the main
repository.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
