#1
- Created on2011-10-10 06:38
- Reported by
- StatusAccepted
- PriorityNormal (3)
- Assigned to
- Milestone
- Plan Level-
- Due Date-
Saving the .zsync file with -k does not rename the file to the final name
When using the -k parameter to tell zsync to keep the .zsync metadata file, the .zsync file is downloaded but it is saved as .zsync.part. Apparently the final rename is not done or does not work.
I. e. this:
C:\arisnova\zsync\zsync\workdir>..\qtcreator-build\zsync.exe -i SoCollaborative_x64_V2.0_20110706-203234_781a0c456a_master.exe -k SoCollaborative_x64_V2.0_20110715-161645_e0c2346d64_build-release_Debug.exe.zsync http://127.0.0.1:5000/Build-2011-07-15_17-01-29/SoCollaborative_x64_V2.0_20110715-161645_e0c2346d64_build-release_Debug.exe.zsync
will result in the .exe file being downloaded correctly, but the .zsync file will be called SoCollaborative_x64_V2.0_20110715-161645_e0c2346d64_build-release_Debug.exe.zsync.part instead of SoCollaborative_x64_V2.0_20110715-161645_e0c2346d64_build-release_Debug.exe.zsync
I. e. this:
C:\arisnova\zsync\zsync\workdir>..\qtcreator-build\zsync.exe -i SoCollaborative_x64_V2.0_20110706-203234_781a0c456a_master.exe -k SoCollaborative_x64_V2.0_20110715-161645_e0c2346d64_build-release_Debug.exe.zsync http://127.0.0.1:5000/Build-2011-07-15_17-01-29/SoCollaborative_x64_V2.0_20110715-161645_e0c2346d64_build-release_Debug.exe.zsync
will result in the .exe file being downloaded correctly, but the .zsync file will be called SoCollaborative_x64_V2.0_20110715-161645_e0c2346d64_build-release_Debug.exe.zsync.part instead of SoCollaborative_x64_V2.0_20110715-161645_e0c2346d64_build-release_Debug.exe.zsync
Leave a comment
on 2011-10-10 16:08 *
By Pau Garcia i Quiles
Milestone set to Second release: 64-bit and large file support
on 2011-10-21 14:50 *
By Pau Garcia i Quiles
Milestone changed from Second release: 64-bit and large file support to Third release
on 2011-10-21 14:54 *
By Pau Garcia i Quiles
Milestone changed from Fourth release to Third release: polish native
on 2011-10-21 20:34 *
By Pau Garcia i Quiles
(In revision:d8058941c614f2bcae931f831da68938404d9d3f) Accepted #1 : Saving the .zsync file with -k does not rename the file to the final name
This commit replaces CRT's fopen with a custom w32_fopen that used CreateFile and opens files with FILE_SHARE_DELETE to allow open files to be renamed.
This fixes the original bug (passing the -k name.zsync ended up in the metadata being saved to name.zsync.part), but there are still a few problems:
- It only works the first time. From the second time on, instead of reading the existing name.zsync, it creates again a name.zsync.part and fails to rename to name.zsync
- w32_fopen does not behave like fopen for the 'wb' and 'wb+' case (probably for all 'w' cases). Apparently CreateFile does not allow dwCreationDisposition = CREATE_NEW | TRUNCATE_EXISTING. Using only CREATE_NEW works but shows the wrong behavior described above from the second time on. Using only TRUNCATE_EXISTING makes zsync not work at all. This breaks also zsyncmake.
Branch:dashk
This commit replaces CRT's fopen with a custom w32_fopen that used CreateFile and opens files with FILE_SHARE_DELETE to allow open files to be renamed.
This fixes the original bug (passing the -k name.zsync ended up in the metadata being saved to name.zsync.part), but there are still a few problems:
- It only works the first time. From the second time on, instead of reading the existing name.zsync, it creates again a name.zsync.part and fails to rename to name.zsync
- w32_fopen does not behave like fopen for the 'wb' and 'wb+' case (probably for all 'w' cases). Apparently CreateFile does not allow dwCreationDisposition = CREATE_NEW | TRUNCATE_EXISTING. Using only CREATE_NEW works but shows the wrong behavior described above from the second time on. Using only TRUNCATE_EXISTING makes zsync not work at all. This breaks also zsyncmake.
Branch:dashk
on 2011-10-21 20:39 *
By Pau Garcia i Quiles
The failure to read the existing name.zsync file seems to be another bug in my w32_fopen :-/
struct zsync_state *read_zsync_control_file(const char *p, const char *fn) {
...
f = fopen(p, "rb");
...
struct zsync_state *read_zsync_control_file(const char *p, const char *fn) {
...
f = fopen(p, "rb");
...
on 2011-12-26 19:48 *
By Pau Garcia i Quiles
Milestone changed from Third release: polish native to Fourth release: achieve perfection