Skip to content
Advertisement

ObjectStream’s magic number in the header is changed while putting file on a linux server

Hope you are doing well. The strange thing happened to me since yesterday.

I have the following code for saving the JSON.

 public static boolean saveCacheJson(String pathToCache, JSONObject json) {
        boolean isSaveSuccess = false;
        ObjectOutputStream outputStream = null;
        FileOutputStream fileOutputStream = null;
        try {
            File file = new File(pathToCache);
            if (!file.exists()) {
                file.getParentFile().mkdirs();
                new FileWriter(file);
            } else {
                file.delete();
            }
            fileOutputStream = new FileOutputStream(pathToCache);
            outputStream = new ObjectOutputStream(fileOutputStream);
            outputStream.writeObject(json.toString());
            isSaveSuccess = true;
        } catch (IOException e) {
            IsoGame.$().crossPlatformManager.getCrossPlatformUtilsInstance().sendLog(e);

            e.printStackTrace();
        } finally {
            try {
                outputStream.close();
            } catch (Exception e1) {
                IsoGame.$().crossPlatformManager.getCrossPlatformUtilsInstance().sendLog(e1);
                e1.printStackTrace();
            }
            try {
                fileOutputStream.close();
            } catch (Exception e1) {
                IsoGame.$().crossPlatformManager.getCrossPlatformUtilsInstance().sendLog(e1);
                e1.printStackTrace();
            }
        }
        return isSaveSuccess;
    }

and the following code for reading it.

public static JSONObject getCacheJson(String pathToCache, boolean throwException) throws Exception {
        JSONObject result = null;
        String resultString;
        ObjectInputStream inputStream = null;
        FileInputStream fileInputStream = null;
        try {
            fileInputStream = new FileInputStream(pathToCache);
            inputStream = new ObjectInputStream(fileInputStream);
            resultString = (String) inputStream.readObject();
            result = new JSONObject(resultString);
        } catch (ClassNotFoundException | IOException | JSONException e) {
            e.printStackTrace();
            if (throwException && e instanceof FileNotFoundException) {
                throw e;
            }
        } finally {
            try {
                if (inputStream != null) {
                    inputStream.close();
                }
            } catch (Exception e1) {
                e1.printStackTrace();
            }
            try {
                if (fileInputStream != null) {
                    fileInputStream.close();
                }
            } catch (Exception e1) {
                e1.printStackTrace();
            }
        }

        return result;
    }

I’m writing the JSON via saveCacheJson and then putting the file to my Server (Linux) and then my ‘front end’ part downloads it and tries to read.

From yesterday I started receiving the following exception.

java.io.StreamCorruptedException: invalid stream header:

After some research and trying to understand what’s going on I found the following.

There is a MAGIC_NUMBER in the ObjectOutputStream class, that used for a header.

protected void writeStreamHeader() throws IOException {
        this.bout.writeShort(-21267);
        this.bout.writeShort(5);
    }

Then, in the ObjectInputStream class the following method is called.

protected void readStreamHeader() throws IOException, StreamCorruptedException {
        short var1 = this.bin.readShort();
        short var2 = this.bin.readShort();
        if (var1 != -21267 || var2 != 5) {
            throw new StreamCorruptedException(String.format("invalid stream header: %04X%04X", var1, var2));
        }
    }

And the exception is thrown here.

So, I opened the file that I write on my local machine (Mac OS) and found the first 2 bytes that are the following

¨Ì

Then I tried the following in the terminal.

hexdump myfile

and found that the first 2 bytes are right. Here is it.

ac ed ... 

So, I tried to do the same for the downloaded file (from Linux server, that I put there before) and found that the first 2 bytes are wrong. So, I checked the flow and found that they have changed during copying the file to the server.

This is strange overall, but the strangest thing is that it worked for about 10 days ago. As I remember, nothing changed in my server.

So, my main question is

ANY IDEAS WHY THE STREAM HEADER IS CHANGED DURING UPLOAD TO LINUX SERVER???

Thanks.

UPDATE

The first 2 shorts in the file BEFORE UPLOAD are.

ac ed 00 05 ...

Which is right.

The first 2 shorts in the file AFTER UPLOADING to linux from Mac are.

bfef efbd ...

Which is wrong.

UPDATE 2.

The result from the right file.

0000000 ac ed 00 05 7c 00 00 00 00 00 0f 26 fe 7b 22 64
0000010 65 22 3a 7b 22 6e 70 63 22 3a 5b 7b 22 63 6f 64
0000020 65 22 3a 22 64 65 22 2c 22 6e 70 63 5f 69 64 22
0000030 3a 32 2c 22 6c 61 6e 67 5f 69 64 22 3a 36 2c 22
0000040 69 64 22 3a 31 32 2c 22 6c 61 6e 67 75 61 67 65
0000050 5f 69 64 22 3a 36 2c 22 64 69 61 6c 6f 67 73 22
0000060 3a 5b 22 53 63 68 61 75 20 6d 61 6c 2c 20 64 61
0000070 73 20 69 73 74 20 49 72 69 73 2c 20 64 65 72 20
0000080 42 6f 74 65 20 64 65 72 20 47 c3 b6 74 74 65 72
0000090 2e 20 53 69 65 20 68 61 74 20 75 6e 73 20 6d 61
..........

And from the Wrong file.

0000000 ef bf bd ef bf bd 00 05 7c 00 00 00 00 00 0f 26
0000010 ef bf bd 7b 22 64 65 22 3a 7b 22 6e 70 63 22 3a
0000020 5b 7b 22 63 6f 64 65 22 3a 22 64 65 22 2c 22 6e
0000030 70 63 5f 69 64 22 3a 32 2c 22 6c 61 6e 67 5f 69
0000040 64 22 3a 36 2c 22 69 64 22 3a 31 32 2c 22 6c 61
0000050 6e 67 75 61 67 65 5f 69 64 22 3a 36 2c 22 64 69
0000060 61 6c 6f 67 73 22 3a 5b 22 53 63 68 61 75 20 6d
0000070 61 6c 2c 20 64 61 73 20 69 73 74 20 49 72 69 73
0000080 2c 20 64 65 72 20 42 6f 74 65 20 64 65 72 20 47
0000090 c3 b6 74 74 65 72 2e 20 53 69 65 20 68 61 74 20

Advertisement

Answer

OK, I found what causes the problem. Not sure why yet, but found how to solve.

I used mypath/myfile.txt as a pathToCache parameter for the saveCacheJson method. So, I found that the problem because of the .txt extension. I removed an extension at all and the problem resolved. It seems the .txt extension is the reason, that Mac’s system doesn’t understand that the file is binary and trying to encode its content during copying. Not sure why the system trying to change the file’s content at all during the copy ))

Advertisement