Shared buffer causes multiple issues with network drives configured

[VanzT]

The following was AI generated after I ran into this issue where two networks 'drives' are not working. I am including this (potentially incorrect) summary anyway in the hopes that it may help. If it is irrelevant, please blame Claude ;) :

Bug: Shared buffer causes multiple issues with network drives configured

Summary

There appear to be multiple issues when network drives are configured in PETDISK.CFG, likely related to shared buffer usage:

1. Multiple network drives don't work - When configuring two or more network drives, neither works. Each works correctly when configured alone.

2. Saving to SD card fails when any network drive is configured - Even when saving to the SD card (device 8), the save fails if a network drive is also configured. The PET loses connection and the file is not present after reset.

Steps to Reproduce

Issue 1: Multiple network drives

1. Create a PETDISK.CFG with a single network drive:

8,SD0
9,10.0.0.181/petdisk.php
ssid,MyNetwork
password,MyPassword

Result: Device 9 works correctly.

2. Create a PETDISK.CFG with two network drives:

8,SD0
9,10.0.0.181/petdisk.php
10,bitfixer.com/pd/petdisk.php
ssid,MyNetwork
password,MyPassword

Result: Neither device 9 nor device 10 works. Directory listings fail for both.

Issue 2: Saving to SD fails when network drive configured

1. Create a PETDISK.CFG with only SD card:

8,SD0

Result: Saving files to device 8 works correctly.

2. Create a PETDISK.CFG with SD card and a network drive:

8,SD0
9,10.0.0.181/petdisk.php
ssid,MyNetwork
password,MyPassword

Result: Saving to device 8 fails - PET loses connection to the device and the file is not present after reset.

Expected Behavior

1. Multiple network drives should work independently, as documented ("Up to 4 network drives can be used at once").
2. Saving to SD card should work regardless of whether network drives are configured.

Actual Behavior

1. With multiple network drives configured, all network drives fail.
2. With any network drive configured, saving to SD card fails - the file data may be written but the directory entry is not created, so the file appears to not exist.

Possible Root Cause

After examining the source code, both issues appear to stem from the same problem: all data sources share a single buffer.

Shared buffer initialization (petdisk.cpp lines 1827-1830):

nds0.initWithParams(&_espHttp, _buffer, &_bufferSize);
nds1.initWithParams(&_espHttp, _buffer, &_bufferSize);
nds2.initWithParams(&_espHttp, _buffer, &_bufferSize);
nds3.initWithParams(&_espHttp, _buffer, &_bufferSize);

All four NetworkDataSource objects share the same _buffer. The FAT32 data source also uses this buffer (as _FatBuffer).

Why Issue 1 occurs (multiple network drives):

When multiple network drives are configured, their HTTP operations share the same buffer and may overwrite each other's data during initialization or access.

Why Issue 2 occurs (SD save fails with network configured):

In writeFile() (petdisk.cpp lines 742-755), after writing file data to SD but before calling closeFile(), the code attempts to fetch the current time from the network:

if (_timeDataSource != NULL && _dataSource->needRealTime())
{
    bool gotTimeDate = _timeDataSource->getCurrentDateTime(&year, &month, &day, &hour, &minute, &second);

• _timeDataSource is set when any network drive is configured (line 486)
• FAT32's needRealTime() returns true
• getCurrentDateTime() makes an HTTP request that uses the shared buffer
• This overwrites _FatBuffer with HTTP response data
• closeFile() then fails to create the directory entry because the buffer is corrupted

I haven't been able to debug this directly, so there may be other contributing factors.

Suggested Fixes

For Issue 1 (multiple network drives):

Allocate separate buffers for each NetworkDataSource, or implement buffer management to prevent concurrent access.

For Issue 2 (SD save with network configured):

Option A: Don't fetch network time during SD save - skip the time fetch or make it conditional:

if (_timeDataSource != NULL && _dataSource->needRealTime() && _dataSource != _fat32)
{
    // only fetch time for network saves, not SD saves
}

Option B: Fetch the time before the save operation begins, storing it in separate variables, rather than after data is written.

Option C: Give FAT32 its own dedicated buffer separate from the network buffer.

Environment

• PETdisk MAX v3 (ESP32)
• Firmware built from current main branch (commit 91522e5)
• Both local (Raspberry Pi) and remote (bitfixer.com) PHP servers tested

Workaround

For now, use separate config files:

• For saving to SD: use a config with only 8,SD0 (no network drives, no ssid/password)
• For loading from network: use a config with network drives (accept that saving to SD won't work)

Additional Notes

• Using http:// prefix in URLs causes a different issue (device hangs when trying to get directory listing) - possibly because strchr(url, '/') finds the / in http:// instead of the path separator
• Non-consecutive device numbers (e.g., 9 and 11) exhibit the same problem for Issue 1
• The SD save issue (Issue 2) was confirmed by testing: save works with SD-only config, fails immediately when network drive is added to config

Happy to provide more information or test any fixes. Thank you for this great project!

[bitfixer]

Thanks very much for the report and analysis. This code is certainly in need of refactoring, and I'll try to take a look at this issue in the next few days! If I find the issue I'll publish a new firmware version with the fix. -Mike

…

On Sun, Nov 30, 2025 at 2:58 PM VanzT ***@***.***> wrote: *VanzT* created an issue (bitfixer/petdisk-max#20) <#20> The following was AI generated after I ran into this issue where two networks 'drives' are not working. I am including this (potentially incorrect) summary anyway in the hopes that it may help. If it is irrelevant, please blame Claude ;) : Summary When configuring two or more network drives in PETDISK.CFG, neither drive works. Each drive works correctly when configured alone. Steps to Reproduce 1. Create a PETDISK.CFG with a single network drive: 8,SD0 9,10.0.0.181/petdisk.php ssid,MyNetwork password,MyPassword *Result:* Device 9 works correctly. 2. Create a PETDISK.CFG with two network drives: 8,SD0 9,10.0.0.181/petdisk.php 10,bitfixer.com/pd/petdisk.php ssid,MyNetwork password,MyPassword *Result:* Neither device 9 nor device 10 works. Directory listings fail for both. Expected Behavior Both network drives should work independently, as documented ("Up to 4 network drives can be used at once"). Actual Behavior With multiple network drives configured, all network drives fail. The device appears to connect to WiFi successfully (2 blinks), but any attempt to access either network drive fails. Possible Root Cause After examining the source code, one possible issue I noticed is in petdisk.cpp at lines 1827-1830: nds0.initWithParams(&_espHttp, _buffer, &_bufferSize); nds1.initWithParams(&_espHttp, _buffer, &_bufferSize); nds2.initWithParams(&_espHttp, _buffer, &_bufferSize); nds3.initWithParams(&_espHttp, _buffer, &_bufferSize); All four NetworkDataSource objects share the same _buffer. It's possible that when the firmware initializes or accesses multiple network drives, they may overwrite each other's data in this shared buffer. However, I haven't been able to debug this directly, so there may be another cause. Suggested Fix (if buffer sharing is the issue) Option 1: Allocate separate buffers for each NetworkDataSource: uint8_t _buffer_nds0[1024]; uint8_t _buffer_nds1[1024]; uint8_t _buffer_nds2[1024]; uint8_t _buffer_nds3[1024]; nds0.initWithParams(&_espHttp, _buffer_nds0, &_bufferSize); nds1.initWithParams(&_espHttp, _buffer_nds1, &_bufferSize); // etc. Option 2: If memory is constrained, implement a buffer management system that ensures only one network operation occurs at a time, with proper synchronization. Environment - PETdisk MAX v3 - Firmware built from current main branch (commit 91522e5 <91522e5> ) - Both local (Raspberry Pi) and remote (bitfixer.com) PHP servers tested Additional Notes - Using http:// prefix in URLs causes a different issue (device hangs when trying to get directory listing) - possibly because strchr(url, '/') finds the / in http:// instead of the path separator - Non-consecutive device numbers (e.g., 9 and 11) exhibit the same problem - Single URLs of any valid length work fine Happy to provide more information or test any fixes. Thank you for this great project! — Reply to this email directly, view it on GitHub <#20>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANYKONP6RKZTBERYUH7MFL37NZDHAVCNFSM6AAAAACNTWYB5CVHI2DSMVQWIX3LMV43ASLTON2WKOZTGY3TQNJWGI4TSMA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>