Hi Synchronicity,
Would it be possible allow user to retrieve the sha1 of a file by giving a path?
A Python API would really be awesome
Regards
Search found 88 matches
- Fri May 26, 2017 4:18 pm
- Forum: wimlib discussion
- Topic: retrieve file sha1
- Replies: 2
- Views: 7632
- Sun Jan 01, 2017 2:12 pm
- Forum: wimlib discussion
- Topic: Happy new year
- Replies: 0
- Views: 16192
Happy new year
Hi Synchronicity,
Just to wish you a happy new year. It's always a pleasure to work with wimlib. All the best for you and wimlib in 2017
Regards
Just to wish you a happy new year. It's always a pleasure to work with wimlib. All the best for you and wimlib in 2017
Regards
- Sun Aug 28, 2016 7:52 pm
- Forum: wimlib discussion
- Topic: wimlib 1.10.0 released
- Replies: 6
- Views: 11785
Re: wimlib 1.10.0 released
By the way, any chance to changed the hard coded 16 (Kbyte or Mbyte don't remember) hole after each file anytime soon in NTFS-3G?
- Sun Aug 28, 2016 7:50 pm
- Forum: wimlib discussion
- Topic: wimlib 1.10.0 released
- Replies: 6
- Views: 11785
Re: wimlib 1.10.0 released
such as my NTFS-3G plugin for system compression (https://github.com/ebiggers/ntfs-3g-system-compression). Nice :) If it's now supported in Linux, I'll try to get it working on Windows 7 (I read it is possible to "backport"). A chunk size like 128 KiB would be more reasonable. For anyone ...
- Sun Aug 28, 2016 3:52 pm
- Forum: wimlib discussion
- Topic: wimlib 1.10.0 released
- Replies: 6
- Views: 11785
Re: wimlib 1.10.0 released
Oh and why not create a fork of ntfs-3G or submit patches? Wimlib is certainly the application which has the most intensive usage of ntfs-3G when applying huge partition images. What you would do with it could only benefit the other applications using it.
- Sun Aug 28, 2016 3:47 pm
- Forum: wimlib discussion
- Topic: wimlib 1.10.0 released
- Replies: 6
- Views: 11785
Re: wimlib 1.10.0 released
Hi,
Wimlib is already the fastest and most storage efficient archiver we got in our real use case. And you manage to still improve performance
Wimlib is already the fastest and most storage efficient archiver we got in our real use case. And you manage to still improve performance
- Sun Aug 14, 2016 3:48 pm
- Forum: wimlib discussion
- Topic: Suggestion: merge capture and append into functionally identical commands
- Replies: 12
- Views: 21435
Re: Suggestion: merge capture and append into functionally identical commands
For some people, not getting spammed with annoying "are you sure?" prompts is a feature. Microsoft ImageX and DISM do not use prompts either. Is understandable. Then capture could be the way to always create a new archive and append would only create one if their is no archive with given ...
- Sun Aug 14, 2016 11:51 am
- Forum: wimlib discussion
- Topic: Suggestion: merge capture and append into functionally identical commands
- Replies: 12
- Views: 21435
Re: Suggestion: merge capture and append into functionally identical commands
Good Idea, in the meantime, asking the user if he want's to overwrite the existing file (for capture) or if he wants to create the archive (in case of append) would be safe. I agree that automatically creating the archive if it doesn't exist for append should be safe. For capture I would also keep i...
- Fri Jul 29, 2016 7:48 pm
- Forum: wimlib discussion
- Topic: Decrease fragmentation when using ntfs-3G
- Replies: 9
- Views: 14327
Re: Decrease fragmentation when using ntfs-3G
Thanks for the clarification Synchronicity Maybe a quick solution in the meantime would be to first write the bigest files and then the smallest, they would better fit in the gaps without fragmentation and the big files would then be contiguous. Maybe as an option to only use it when beneficial.
- Wed Jul 27, 2016 9:50 pm
- Forum: wimlib discussion
- Topic: Decrease fragmentation when using ntfs-3G
- Replies: 9
- Views: 14327
Re: Decrease fragmentation when using ntfs-3G
Thanks for the investigation. Does ntfsfallocate have the same 16MB "buffer" problem (or is ntfs_attr_truncate_solid() the way to call ntfsfallocate)?
If it's really a failed design, I hope it get fixed soon upstream.
If it's really a failed design, I hope it get fixed soon upstream.