v3.0.0

[3.0.0] — 2026-10-05

Schema: 42. The queue table is rebuilt so an id is never given out twice; queued changes
are kept. Queued changes get a column for the reason Drive refused them, and two for the
content a new file was sent with and where, and name their file and folder by local id as well
as by Drive's id. Stored files and folders name their parent
folder by local id too. A file or folder made on this machine that Drive does not have yet goes
by its local id, in the queue, the stored tree and pins alike.

Added

• Sync issues. A change Drive refuses because the storage is full, access was taken away,
  its folder is gone, a folder limit is reached or Drive rejected it shows up at once as needing
  attention, with what it means and what to do, instead of after six failed attempts. The
  change stays queued and is still retried.
• Export a queued file. The Sync page's Export button and pdfs sync export <id> <dest>
  save a copy of a queued upload's content. The upload stays queued.
• pdfs sync issues lists the changes that need attention; pdfs sync queue shows the
  issue next to each change.
• Discard a queued change. The Sync page's Discard button and pdfs sync discard <id> drop
  a change Drive will not take and undo it here: a new file or folder goes, anything else goes
  back to what Drive has. Export a file first to keep its content.
• Sync issues show on the file. A file or folder with a change Drive refused carries a
  warning badge in the file browser, and its tooltip says what it means and what to do.

Changed

• Making, renaming and deleting through the mount no longer waits for Drive. A new folder,
  a new file, a rename or a delete is recorded locally and the call returns at once; the queue
  sends it, as it does offline. "local_first": false in config.json brings back the old way
  for this release.
• The queue sends up to 16 changes at once instead of 3. A thousand new files in a hundred
  folders reach Drive about three times as fast on a LAN, and four times as fast on Wi-Fi.

Fixed

• A file made under the name of a file whose upload is still going out keeps its name. It
  no longer lands as a conflict copy, and the mount no longer shows that copy's name (B154).
• A change to a file no longer lands as a conflict copy of itself when the link loses Drive's
  answer to its upload (B155).
• A file written again while its upload was being retried no longer lands as a conflict copy
  of itself when the link lost Drive's answer to the first try (B156).
• Writing to a file twice in a row no longer fails with "Input/output error" when the link
  lost Drive's answer to reading back the file's last upload (B157).
• A file renamed twice in a row, while the first name was still taken, keeps the second name
  (B158).
• Opening a file right after the daemon restarts no longer fails with "Resource temporarily
  unavailable" (B159).
• A new folder, or a new empty file, reaches Drive at once, not up to half a minute later
  (B160, B192).
• A file moved while it was still being uploaded keeps its new name in the mount on a slow
  link (B161).
• A folder removed and made again at once keeps what goes into it. It used to be created
  inside the removed folder and was trashed along with it (B162).
• A new file no longer reads as empty just after it is uploaded. Drive can list it a moment
  before its contents are committed, and the mount took that answer (B163).
• A folder no longer lists a new file twice while it is uploaded. A listing taken as the
  upload landed showed it both as Drive had it and as the queue did (B164).
• Stopping the daemon no longer hangs until systemd kills it. A stop waits up to 10 s for
  work in progress, then exits and logs what was still running (B165).
• A folder no longer drops or empties a new file while others are uploaded. A file whose
  upload landed while the folder was being listed was missing from that listing, or listed as
  empty (B166).
• The mount comes up faster on a large Drive. Rebuilding the folder listings from the cache
  took close to 2 s with 37,000 files at every start (B167).
• Files deleted with their folder while uploading stay deleted. The mount no longer tries
  to upload them to the top of your Drive instead (B168).
• Stopping the daemon during a folder sync no longer waits for the sync. The uploads in
  progress finish, and the rest waits for the next start (B169).
• Writing to a file again just as its upload finishes no longer fails. A write right after
  it failed with "Input/output error" (B170).
• A file deleted while its upload was retrying is removed from Drive right away. It no
  longer waits for the upload's next retry (B171).
• A file deleted just as it reached Drive is removed from Drive too. It no longer stayed
  there, and the next file with that name no longer became a conflict copy (B173).
• Renaming a file just as it reaches Drive no longer fails with "Permission denied"
  (B174).
• A file replaced by a rename just as it reached Drive is removed from Drive too. It no
  longer stayed there, and the next rename of its name no longer moved it instead (B175).
• A write closed just as its file reached Drive is no longer lost (B176).
• Opening a folder just as it reaches Drive no longer fails with "Input/output error"
  (B177).
• Deleting a folder while sync is paused no longer leaves a queued change behind for a
  file in it that was never uploaded (B178).
• A file read just as it reaches Drive no longer reads empty (B179).
• Stopping the daemon no longer takes 10 seconds more than it needs when an idle upload
  worker missed the stop (B180).
• A folder made while offline or with sync paused no longer fails with "Input/output
  error" once it is refreshed or the connection comes back (B125).
• The daemon no longer hangs when a file being read changes on Drive (B130).
• The Activity page says in your language why an edit was kept as a conflicting copy,
  instead of the daemon's English (B181).
• A file written after a restart no longer lands as a conflict copy of itself when the
  connection dropped just as it first reached Drive (B182).
• A file deleted after a restart is removed from Drive too when the connection lost Drive's
  answer to its upload and the file was written again meanwhile. It no longer stayed there and
  turned the next file under its name into a conflict copy (B183).
• A file renamed while the connection lost Drive's answer to its upload lands once. It no
  longer stayed on Drive under its old name too, or, when deleted, under its old name alone
  (B184).
• A new file written again just as it starts uploading no longer waits out a retry before
  it reaches Drive (B185).
• A file deleted while open can still be read and written until it is closed, offline too.
  A write into it no longer failed with "Input/output error" (B186).
• An uploaded file no longer leaves a copy of itself in the cache until the next start
  (B187).
• Changes that failed during a short outage go out soon after the connection is back, not
  after a retry delay of up to five minutes (B189).
• A file saved just before the daemon stops reaches Drive with what was written. It could
  keep its old content, or stay empty (B190).
• A file renamed just as its upload finished keeps its new name. The mount no longer showed
  the old name, and a second rename no longer failed with "No such file or directory" (B152,
  B172).
• A change that waits for a name to be freed no longer waits seconds after it is. A rename or
  upload over a file being deleted goes out as soon as the delete lands (B153).
• A file deleted right after it was made no longer stays on Drive when the link lost Drive's
  answer. The node Drive made is trashed (B151).
• A new file no longer lands twice when the link loses Drive's answer to its upload. The
  file Drive made is taken as it is, instead of a second upload as a conflict copy (B127).
• A change to a file deleted elsewhere, together with its folder, no longer retries forever.
  The conflict copy that keeps it now lands in the location's root (B150).
• pdfs rename and pdfs move right after a change through the mount are no longer undone.
  They are queued behind it, and they work on a file that has not reached Drive yet (B149).
• A folder kept offline before it reached Drive stays kept offline. Its pin was lost when the
  folder landed (B148).
• A queued change no longer holds up the queue forever on a link that stops answering.
  Sending a new folder, a delete or a file waits at most 20 seconds for Drive, plus time for
  the file's size, and then the queue treats the link as down and tries again.
• A file deleted while its first upload is on the wire no longer stays on Drive. The node
  the upload made is trashed as soon as it lands, so its name is free again (B129).
• A delete queued while a rename is sent is no longer lost. The rename landing could remove
  the delete from the queue, leaving the file on Drive (B137).
• A file made offline over one deleted offline is no longer lost. Its upload could take
  over the deleted file, and the delete then took the new bytes along with it (B128).
• A file deleted while its upload is on the wire no longer comes back as a recovered-…
  copy when another file is made right after (B133).
• A file made where another one is leaving no longer lands as a conflict copy. Its upload
  waits for the rename or trash that frees the name (B126, B138).
• A file closed just as its first upload lands keeps its last write. The write was refused
  and left in staging (B139).
• Files made in a new folder are still there after a restart. A folder that landed as the
  daemon stopped, or one listed from Drive while files in it were queued, came back empty
  (B132, B140).
• A file renamed twice in quick succession ends up under the second name. The first rename
  could land after the second and undo it (B141).
• Renaming a new file just as its upload lands no longer fails with "Device or resource
  busy". The rename goes to the file Drive made (B142).
• A file whose upload landed just as the connection dropped no longer gets a conflict copy at
  its next save. The daemon reads the file back once the connection returns (B143).
• A rename whose target name was just freed no longer lands as a conflict copy. The rename
  is sent once more under the name it asked for (B144).
• Saving a download under its final name no longer fails with "Device or resource busy".
  A file made a moment before was taken for deleted and dropped from the queue (B145).
• A file renamed just as its upload lands keeps its new name. The tree could take back the
  name Drive still had (B146).
• A new file made under a name another file just left no longer takes that file's place on
  Drive. Both could land on one node, and one file's content was lost (B147).