If a local file is being opened, now the function tries to convert
the path into a URI. This seems to be a more reliable way to open file
on Windows 10 that has a more strict permission policy on cmd.exe.
Previously the CRC error was quite annoying to recover because
the user needed to manually delete the corrupted file from the
staging folder (without knowing the exact path of the file to
remove).
Now the IDE tries autonomously to resolve the situation by
removing the file and downloading it again.
Fixes#5394#4303
This regression originates from:
8725bb1e Clean up sketch loading
before this commit the sketch name sanitization was made on the sketch
name without the extension.
After 8725bb1e instead the name sanitization is made on the filename, so
including the ".ino" extension.
This lead to a weird corner case, caused by the limit of 63 characters
on the sketch name: before 8725bb1e it would be possible to save a sketch
with a name of exactly 63 characters, but after 8725bb1e this sketch will
suddenly becomes invalid becuase the 63 chars name + extension would exceed
the 63 characters limit.
This commit fix this regression.
Fix#5431
Previously, this used a hash of the sketch filename, so the same build
path would be generated for the same sketch between multiple
compilations. Now that the build path is stored, this requirement has
disappeared, so a random filename can be generated again. While here,
this commit also changes the prefix from "build" to "arduino_build_",
which makes it a bit more clear what the directory's purpose is.
Previously, everywhere where it was needed, the path was requested from
BaseNoGui. Because the path is based on a hash of the sketch filename,
every caller would get the same path for the same sketch.
However, it makes more sense to store the path used for a given sketch
inside the Sketch object. This prevents having to pass around or
regenerate the build path everywhere, and no longer requires the build
path to be deterministic (though it still is in this commit).
This allows removing some methods and constructors of which two versions
were available - one with a build path argument and one without.
Previously, callers of `SketchFile.delete()` would also call
`Sketch.removeFile()`, but letting SketchFile handle this is more
robust.
This is possible now that SketchFile keeps a reference to Sketch and
makes updating the Sketch file list less fragile.
Eventually this might be further decoupled by letting SketchFile
broadcast a "deleted" event instead.
This isn't much code, but it makes deletion more consistent with
renaming and saving with the SketchController handling the UI part and
Sketch actually doing the delete.
Now that SketchFile keeps a reference to its Sketch,
`SketchFile.renameTo()` can call `Sketch.checkNewFilename()`, so there
is no need for the renaming itself to go through Sketch.
This changes the parameter for `SketchFile.renameTo()` from File to
String, to enforce that only the filename is changed, not the directory
name.
These methods shouldn't really be in Base (or BaseNoGui, which did the
actual work), especially since there is already a
`FileUtils.recursiveDelete()` which just does the same thing. This
commit removes the code from Base and BaseNoGui and instead uses the
method from FileUtils.
There is one difference between these methods: the Base methods did not
delete files if the "compiler.save_build_files" preference was set.
However, the Base methods were only used when deleting a sketch, or
deleting an existing folder before overwriting it on save as, so this
preference didn't actually do what it was supposed to anyway, so
dropping it shouldn't be a problem.
Cristian Maglie
Martino Facchin
Matthijs Kooijman