Search found 472 matches
- Tue Apr 26, 2016 11:26 pm
- Forum: wimlib discussion
- Topic: process stays at 99% sometime and write a lot to disk
- Replies: 11
- Views: 19248
Re: process stays at 99% sometime and write a lot to disk
wimlib tries to compress all files, regardless of file extension or file format, since it cannot predict, in general, whether the data will be compressible or not. Note that if the data is incompressible, then the compression speed will be much faster than if the data is moderately compressible. In ...
- Sun Apr 24, 2016 3:05 pm
- Forum: wimlib discussion
- Topic: process stays at 99% sometime and write a lot to disk
- Replies: 11
- Views: 19248
Re: process stays at 99% sometime and write a lot to disk
1.) The first thing probably appears to take little CPU time because that particular workload happens to be I/O bound. I don't understand what you mean by "wim archives are being recompressed". 3.) The "Archiving file data" progress is reported in terms of bytes, not files. So it...
- Thu Apr 21, 2016 10:46 pm
- Forum: wimlib discussion
- Topic: adding the list of reference wim to an xml
- Replies: 2
- Views: 6315
Re: adding the list of reference wim to an xml
Do you mean the XML document inside the WIM file? That might make sense, although it gets a little complicated if you try to work through the details of how a referenced WIM file would be identified and then found again automatically later (by path? by name? by GUID?). Then there are the questions o...
- Sun Apr 17, 2016 3:45 pm
- Forum: wimlib discussion
- Topic: Revealing unknown_0x14 in struct WimOverlay_dat_header
- Replies: 2
- Views: 6048
Re: Revealing unknown_0x14 in struct WimOverlay_dat_header
I've posted wimlib 1.9.2-BETA1. It should handle the field correctly.
- Sun Apr 17, 2016 2:18 pm
- Forum: wimlib discussion
- Topic: Revealing unknown_0x14 in struct WimOverlay_dat_header
- Replies: 2
- Views: 6048
Re: Revealing unknown_0x14 in struct WimOverlay_dat_header
Thanks for the tip! Yes,it looks like your suggested interpretation is correct. I think I did not check what the file looks like after unregistering a WIM from the volume, since that is the case where the two fields diverge. next_data_source_id becomes greater than the number of entries, since data ...
- Sat Apr 16, 2016 1:41 am
- Forum: wimlib discussion
- Topic: process stays at 99% sometime and write a lot to disk
- Replies: 11
- Views: 19248
Re: process stays at 99% sometime and write a lot to disk
Was this on a system with a lot of memory? It's possible the operating system was just catching up with previously buffered writes. On modern operating systems, data written by applications is usually stored in memory and flushed to disk asynchronously. Applications do not have much, if any, visibil...
- Sat Apr 09, 2016 3:30 am
- Forum: wimlib discussion
- Topic: Files with the same modification date and size in delta backups
- Replies: 7
- Views: 19050
Re: Files with the same modification date and size in delta backups
Okay, thanks. It seems this is a rather blatant bug in Windows. The last modification time of a file is not updated each time a write is made. I just verified it myself, but it also has been reported by many other people: https://blogs.technet.microsoft.com/asiasupp/2010/12/14/file-date-modified-pro...
- Fri Apr 08, 2016 3:05 pm
- Forum: wimlib discussion
- Topic: Huge slowdown when archive size increase
- Replies: 14
- Views: 23587
Re: Huge slowdown when archive size increase
I really have no idea. I don't believe wimlib isn't doing anything unusual with the output WIM file. It opens it for writing and writes to it mostly sequentially. Sometimes it seeks slightly backwards and overwrites bytes it recently wrote. I don't think it's an unusual access pattern at all, so if ...
- Fri Apr 08, 2016 2:46 pm
- Forum: wimlib discussion
- Topic: Files with the same modification date and size in delta backups
- Replies: 7
- Views: 19050
Re: Files with the same modification date and size in delta backups
Well, that's disappointing. If Windows really can do that, then the --update-of option cannot be guaranteed to work on Windows.
Is there any possibility the system was uncleanly shut down? I could imagine that could, in some situations, cause data changes to be persisted before metadata changes.
Is there any possibility the system was uncleanly shut down? I could imagine that could, in some situations, cause data changes to be persisted before metadata changes.
- Sat Apr 02, 2016 3:51 am
- Forum: wimlib discussion
- Topic: Huge slowdown when archive size increase
- Replies: 14
- Views: 23587
Re: Huge slowdown when archive size increase
Any news about the results on Windows 7? Unfortunately, I don't have a copy of Windows Server 2003 available for testing, and in general it is difficult for me to invest time into testing with outdated operating systems. Also: wimlib almost always runs exactly the same code on all versions of Window...