I'm attaching a squashfs image containing a symlink named "link" and a regular file named "file". The symlink has a timestamp of "25 Aug 91 20:57:08 GMT".
** Description changed: + [Impact] + + * The unsquashfs utility does not preserve atime and mtime timestamps + of symlink inodes when unpacking squashfs images. + + * This makes it impossible to use a combination of unsquashfs and + mksquashfs to sanity check snaps uploaded to the snap store since + the resulting snap will not match the original snap due to symlink + times being set to the current time when unsquashfs was executed. + + [Test Case] + + * TODO + + [Regression Potential] + + * The regression potential is small as long as there is no software + out there that depends on the behavior of setting symlink timestamps + to the current time. I highly doubt that there is anything out there + that relies on that behavior but there's always a chance. + + [Original Descipription] + Create the files: $ mkdir test $ cd test $ touch foo $ ln -s foo bar $ mkdir meta $ cat >meta/snap.yaml <<EOM name: test version: 1.0 architectures: [all] EOM Create the initial snap $ cd .. $ snapcraft snap ./test ... Snapped test_1.0_all.snap Unsquash the snap: $ unsquashfs -d unsquashed test_1.0_all.snap Parallel unsquashfs: Using 4 processors 3 inodes (2 blocks) to write [=======================================================================|] 2/2 100% created 2 files created 2 directories created 1 symlinks created 0 devices created 0 fifos Resquash the snap (the sleep is to make sure the time changes on the symlink): $ unsquashfs -fstime ./test_1.0_all.snap 1457551603 $ mksquashfs ./unsquashed ./test_1.0_all.snap.repacked -fstime 1457551603 -noappend -comp xz -all-root -no-xattrs ... - Compare: $ sha512sum test_1.0_all.snap 40a15430503783541b362942491ee614b16941676d6c3edd86005af7b6b0782374e41c0c006dccb3a164d2c0270ace66639fcdee5ece3571db1c7544d59030e3 test_1.0_all.snap - $ sha512sum test_1.0_all.snap.repack + $ sha512sum test_1.0_all.snap.repack d8b9626337b8f09288f6aab675041dba639523437dd1d8f11b3f883cfa73ea434f2be06f5cd9cdec4ac9bdf2a40f8b484dc516ec851870c81be133cbdebf35a4 test_1.0_all.snap.repack - Removing the symlink makes the check work. ** Attachment added: "lp1555305.squashfs" https://bugs.launchpad.net/ubuntu/+source/squashfs-tools/+bug/1555305/+attachment/5021493/+files/lp1555305.squashfs ** Description changed: [Impact] - * The unsquashfs utility does not preserve atime and mtime timestamps - of symlink inodes when unpacking squashfs images. + * The unsquashfs utility does not preserve atime and mtime timestamps + of symlink inodes when unpacking squashfs images. - * This makes it impossible to use a combination of unsquashfs and - mksquashfs to sanity check snaps uploaded to the snap store since - the resulting snap will not match the original snap due to symlink - times being set to the current time when unsquashfs was executed. + * This makes it impossible to use a combination of unsquashfs and + mksquashfs to sanity check snaps uploaded to the snap store since + the resulting snap will not match the original snap due to symlink + times being set to the current time when unsquashfs was executed. [Test Case] - * TODO + * Extract the test image: + $ unsquashfs -d lp1555305 lp1555305.squashfs + + * Check the timestamp of the "link" file + $ ls -al lp1555305/link + + * Incorrect output (timestamp will be current time): + lrwxrwxrwx 1 tyhicks tyhicks 4 Dec 11 22:05 link -> file + + * Expected output: + lrwxrwxrwx 1 tyhicks tyhicks 4 Aug 25 1991 /tmp/lp1555305/link -> file [Regression Potential] - * The regression potential is small as long as there is no software - out there that depends on the behavior of setting symlink timestamps - to the current time. I highly doubt that there is anything out there - that relies on that behavior but there's always a chance. + * The regression potential is small as long as there is no software + out there that depends on the behavior of setting symlink timestamps + to the current time. I highly doubt that there is anything out there + that relies on that behavior but there's always a chance. [Original Descipription] - + Create the files: $ mkdir test $ cd test $ touch foo $ ln -s foo bar $ mkdir meta $ cat >meta/snap.yaml <<EOM name: test version: 1.0 architectures: [all] EOM Create the initial snap $ cd .. $ snapcraft snap ./test ... Snapped test_1.0_all.snap Unsquash the snap: $ unsquashfs -d unsquashed test_1.0_all.snap Parallel unsquashfs: Using 4 processors 3 inodes (2 blocks) to write [=======================================================================|] 2/2 100% created 2 files created 2 directories created 1 symlinks created 0 devices created 0 fifos Resquash the snap (the sleep is to make sure the time changes on the symlink): $ unsquashfs -fstime ./test_1.0_all.snap 1457551603 $ mksquashfs ./unsquashed ./test_1.0_all.snap.repacked -fstime 1457551603 -noappend -comp xz -all-root -no-xattrs ... Compare: $ sha512sum test_1.0_all.snap 40a15430503783541b362942491ee614b16941676d6c3edd86005af7b6b0782374e41c0c006dccb3a164d2c0270ace66639fcdee5ece3571db1c7544d59030e3 test_1.0_all.snap $ sha512sum test_1.0_all.snap.repack d8b9626337b8f09288f6aab675041dba639523437dd1d8f11b3f883cfa73ea434f2be06f5cd9cdec4ac9bdf2a40f8b484dc516ec851870c81be133cbdebf35a4 test_1.0_all.snap.repack Removing the symlink makes the check work. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1555305 Title: resquashfs test fails if snap has symlinks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/click-reviewers-tools/+bug/1555305/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
