Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

appimage-extract(-and-run) don't preserve file timestamps #1151

Open
realnc opened this issue Sep 23, 2021 · 6 comments · May be fixed by #1216
Open

appimage-extract(-and-run) don't preserve file timestamps #1151

realnc opened this issue Sep 23, 2021 · 6 comments · May be fixed by #1216

Comments

@realnc
Copy link

realnc commented Sep 23, 2021 •
edited
Loading

I wanted to fix this issue myself, seemed easy enough. Probably in runtime.c where this line is:

chmod(prefixed_path_to_extract, st.st_mode);

Don't just apply permissions but also timestamps. However, since AppImageKit doesn't seem to be able to be compiled on modern systems, I can't add this myself.

As for why:

Not restoring timestamps breaks code that checks cache validity through timestamps. For example in one of my applications that I ship as an AppImage, I bundle LibVLC and its plugins into the AppImage. Before the creation of the image, I generate the usr/lib/vlc/plugins/plugins.dat file. This speeds up VLC plugin loading. However, if the timestamps of the plugins changes, which happens when running the AppImage with --appimage-extract-and-run, LibVLC prints countless error messages about every plugin. One example:

main libvlc error: stale plugins cache: modified /tmp/appimage_extracted_1e2e0dbe8053a3543648ca6c3c5a71fb/usr/lib/vlc/plugins/packetizer/libpacketizer_h264_plugin.so

As a result, the cache isn't used at all. This is not the end of the world, since it's a soft error, but still it would be nice if timestamps were preserved when extracting.
@probonopd
Copy link
Member

probonopd commented Sep 23, 2021 •
edited
Loading

Agree that extracting should obey creation timestamps, sounds reasonable to me. What about modification timestamps? How is this normally done by unarchiving programs?

What do others think?

@realnc
Copy link
Author

realnc commented Sep 23, 2021 •
edited
Loading

According to stat, both cp -a as well as tar preserve modification time. They only change access time and "change" time. ("Change" time seems to be the time the file's metadata, like access permissions, were changed.)

Example:

$ stat some_file
File: some_file
  Size: 72965           Blocks: 144        IO Block: 4096   regular file
Device: 22h/34d Inode: 254422      Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  realnc)   Gid: ( 1000/  realnc)
Access: 2021-09-24 00:09:33.648484504 +0300
Modify: 2019-04-06 03:41:26.000000000 +0300
Change: 2021-09-24 00:09:33.648484504 +0300
 Birth: -

"Access" and "Change" times were updated to current time. "Modify" time was preserved. Indeed, if I run the AppImage normally without extracting it, and while the application is open I either cp -a /mnt/.mount_Application-ID to somewhere else, or do tar cf app.tar /mnt/.mount_Application-ID and then untar it and run the application from the copy, it works correctly. Modification time is what matters.

@probonopd
Copy link
Member

I think we should mirror the behavior of tar, do you agree?

@realnc
Copy link
Author

realnc commented Sep 25, 2021

I think we should mirror the behavior of tar, do you agree?

Yes. I looked at some other formats as well, and they all do the same thing as tar.

@probonopd
Copy link
Member

Great, so we know what we should do.
Pull requests would be highly welcome!

@realnc
Copy link
Author

realnc commented Sep 25, 2021

#1084 (comment)

lalten added a commit to lalten/AppImageKit that referenced this issue Sep 20, 2022
@lalten
Preserve timestamps when extracting the squashfs
3a1b4f0 
Closes AppImage#1151
@lalten lalten linked a pull request Sep 20, 2022 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Preserve timestamps when extracting the squashfs lalten/AppImageKit
2 participants
@realnc @probonopd