Incorrect progress on pulling large files

[Alex4SSB]

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

1. Connect a device
2. Create a sync service
3. 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

[Alex4SSB]

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()

[wherewhere]

[wherewhere]

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

Please try it on your device.

[Alex4SSB]

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.

[wherewhere]

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.

[wherewhere]

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.

[Alex4SSB]

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.

[wherewhere]

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

[wherewhere]

Weird...

[wherewhere]

OK. Got it.

[Alex4SSB]

Great!

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

Also, it probably should be called CreationTime, not ChangeTime

[wherewhere]

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.