Incorrect progress on pulling large files

Describe the bug

SyncProgressChangedEventArgs during pull of large files:

• For files where the size in bytes has the 32nd bit set 1, 2,329,488,011 bytes in this case, the progress is negative (from start to finish). See screenshot 1.

• For files where the size in bytes has the 33rd bit set 1, 5,079,805,952 bytes in this case, the progress surpasses 100 at some point. See screenshot 2.

Steps to reproduce the bug

Connect a device
Create a sync service
Pull a large file (as specified) while providing SyncProgressChangedEventArgs callback

Expected behavior

The progress should always be between 0 and 100, as specified.
Also, the TotalBytesToReceive doesn't seem right.

Screenshots

Screenshot 1:

Screenshot 2:

NuGet package version

3.4.14 (later verified in 3.5.15)

.NET Platform

.NET 9

Platform type

Windows

System version

Windows 11 64bit.
The app is only compiled for x64.

IDE

Visual Studio 2026

More Context

Original Issue:
Alex4SSB/ADB-Explorer#290

In AdvancedSharpAdbClient\Extensions\EnumerableBuilder.cs line 54: Size = ReadInt32(values),.
Generally, stat returns the file size as UInt64, not sure where this FileStatistics data is originally generated.

So this should affect not only pull progress, but also DeviceExtensions.Stat()

Change FileStatistics.Size to uint32 #133

I have no idea why it returns a wrong size...

Please try it on your device.

Yes, the size you got is incorrect since you lack the 33rd bit:
If the actual size is 4,640,997,376 then the 33rd bit is set 1. If you take it away (by having only 32 bits, you get 346,030,080 instead.

I don't know what happens behind the scenes in the case of AdvancedSharp, but if you run adb shell stat [file name] (in any format), you will get the real size, in this case 4,640,997,376. In other words, pure stat gives the size as UInt64, not UInt32. In your code you get a byte array from somewhere, and you take 32bits for the size, but it is preceded and succeeded by more data, so simply changing it to UInt64 will only take irrelevant info into the size.

So my guess is, it's the thing that gives you the byte array that needs looking into.

It only have 12 bytes, which 4 bytes per field.
https://github.com/SharpAdb/AdvancedSharpAdbClient/blob/main/AdvancedSharpAdbClient/SyncService.cs#L433-L435
I can't get more bytes because it doesn't have more.

Structure defined by Google said size is uint32 in stat v1.
https://android.googlesource.com/platform/system/adb/+/refs/heads/main/file_sync_service.h

union syncmsg {
    struct __attribute__((packed)) {
        uint32_t id;
        uint32_t mode;
        uint32_t size;
        uint32_t time;
    } stat_v1;
    struct __attribute__((packed)) {
        uint32_t id;
        uint32_t error;
        uint64_t dev;
        uint64_t ino;
        uint32_t mode;
        uint32_t nlink;
        uint32_t uid;
        uint32_t gid;
        uint64_t size;
        int64_t atime;
        int64_t mtime;
        int64_t ctime;
    } stat_v2;
    struct __attribute__((packed)) {
        uint32_t id;
        uint32_t mode;
        uint32_t size;
        uint32_t time;
        uint32_t namelen;
    } dent;
    struct __attribute__((packed)) {
        uint32_t id;
        uint32_t size;
    } data;
    struct __attribute__((packed)) {
        uint32_t id;
        uint32_t msglen;
    } status;
};

I don't know how to get stat v2.

Yes, I just looked at this now.
In SyncCommand enum you already have STA2 defined, you just never use it. Can you try Socket.SendSyncRequest(SyncCommand.STA2, remotePath); ? Of course, you will need to adjust the response parsing.

I tried compiling the code myself but I have some 150 errors.

I tried compiling the code myself but I have some 150 errors.

Set FullTargets to false to avoid not installed platform.

https://github.com/SharpAdb/AdvancedSharpAdbClient/blob/main/Directory.Build.props#L30-L30

Weird...

OK. Got it.

Great!

Although the change time looks weird - GTA Vice City was released in 2002...

Also, it probably should be called CreationTime, not ChangeTime

It said ctime is Change Time.

https://www.howtogeek.com/517098/linux-file-timestamps-explained-atime-mtime-and-ctime/#:~:text=Every%20Linux%20file%20has%20three%20timestamps%3A%20the%20access,the%20file%20or%20read%20some%20values%20from%20it.

1996 is because the file has wrong change time.

Ok, can you release a new version with the fix please?

No, the sync v2 has a lot of things. I need to add them all. Also need to add tests for them.
You can get CI packages at here.
(I will push the commit tomorrow so that the commit can count as tomorrow. By the way, I will create a new branch to finnish the sync v2 so that it won't publish to github package...

Add stat v2 and list v2 #133

Published https://github.com/SharpAdb/AdvancedSharpAdbClient/releases/tag/v3.6.16

Navigation Menu

Repository navigation

Incorrect progress on pulling large files #133

Describe the bug

Steps to reproduce the bug

Expected behavior

Screenshots

NuGet package version

.NET Platform

Platform type

System version

IDE

More Context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Incorrect progress on pulling large files #133

Description

Describe the bug

Steps to reproduce the bug

Expected behavior

Screenshots

NuGet package version

.NET Platform

Platform type

System version

IDE

More Context

Activity

Alex4SSB commented on Jan 6, 2026

wherewhere commented on Jan 7, 2026

wherewhere commented on Jan 7, 2026

Alex4SSB commented on Jan 7, 2026

wherewhere commented on Jan 7, 2026

wherewhere commented on Jan 7, 2026

Alex4SSB commented on Jan 7, 2026

wherewhere commented on Jan 8, 2026

wherewhere commented on Jan 8, 2026

wherewhere commented on Jan 8, 2026

Alex4SSB commented on Jan 8, 2026

wherewhere commented on Jan 8, 2026

Alex4SSB commented on Jan 8, 2026

wherewhere commented on Jan 8, 2026

wherewhere commented on Jan 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions