We ran into a similar (but not identical) problem. In diganosing, I noticed FilePath.writeToTar() eats the exception from scan() when there is a subsequent exception on close() (which there usually is). If writeToTar() were to report the first exception, it would probably make debugging easier.
--- core/src/main/java/hudson/FilePath.java (revision 48e42ae94a693a7d83c61ad0bb60f0ec397b5e8c)
+++ core/src/main/java/hudson/FilePath.java (revision )
@@ -2257,11 +2257,24 @@
*/
private Integer writeToTar(File baseDir, DirScanner scanner, OutputStream out) throws IOException {
Archiver tw = ArchiverFactory.TAR.create(out);
+ IOException ioException = null;
try {
scanner.scan(baseDir,reading(tw));
+ } catch (IOException e) {
+ ioException = e;
} finally {
+ try {
- tw.close();
+ tw.close();
+ } catch (IOException e) {
+ // ignore the exception thrown by close if scan already threw an exception
+ if (null == ioException) {
+ ioException = e;
- }
+ }
+ }
+ }
+ if (null != ioException) {
+ throw ioException;
+ }
return tw.countEntries();
}
In our case, we did not have permissions to create a directory, which would have been more clear if the mkdir had reported an error.
--- core/src/main/java/hudson/FilePath.java (revision 48e42ae94a693a7d83c61ad0bb60f0ec397b5e8c)
+++ core/src/main/java/hudson/FilePath.java (revision )
@@ -2281,7 +2294,7 @@
mkdirs(f);
} else {
File parent = f.getParentFile();
- if (parent != null) mkdirs(parent);
+ if (parent != null) mkdirsE(parent);
writing(f);
if (te.isSymbolicLink()) {
|