Prevent Rclone from moving a file if it's open by another process?

What is the problem you are having with rclone?

We have multiple MFP printers that we use to scan documents into an SMB share. Next year, we're migrating to Chrome OS, so I'd rather not have two sets of credentials (one for G Suite, one for Active Directory for the SMB share), so I'm experimenting and found that I could just have an SMB share that Rclone routinely checks and moves files from their to their respective locations in Google Drive. The only problem I'm having so far, is that Rclone is uploading a copy while the file is in use - is there a way I can tell Rclone NOT to try moving a file if it's in use by another process? I do not want scans being uploaded partially before the scanner is finished writing the file.

Thank you! :slight_smile:

What is your rclone version (output from rclone version)

rclone v1.53.3
-os/arch: windows/amd64
-go version: go1.15.5

Which OS you are using and how many bits (eg Windows 7, 64 bit)

Windows Server 2019 64-bit

Which cloud storage system are you using? (eg Google Drive)

Google Drive

The command you were trying to run (eg rclone copy /tmp remote:tmp)

rclone.exe move L:\Scans Scans_Drive:

The rclone config contents with secrets removed.

[Scans_Drive]
type = drive
scope = drive
root_folder_id = 
service_account_file = C:\Program Files\Rclone\Service Accounts\rclone-scans-drive.json
team_drive = (hidden)

A log from the command with the -vv flag

rclone: Version "v1.53.3" starting with parameters ["rclone.exe" "move" "L:\\Scans" "Scans_Drive:" "--config" "C:\\Program Files\\Rclone\\rclone.conf" "-vv"]
2020/12/10 13:36:25 DEBUG : Creating backend with remote "L:\\Scans"
2020/12/10 13:36:25 DEBUG : Using config file from "C:\\Program Files\\Rclone\\rclone.conf"
2020/12/10 13:36:25 DEBUG : fs cache: renaming cache item "L:\\Scans" to be canonical "//?/L:/Scans"
2020/12/10 13:36:25 DEBUG : Creating backend with remote "Scans_Drive:"
2020/12/10 13:36:26 DEBUG : Google drive root '': Waiting for checks to finish
2020/12/10 13:36:26 DEBUG : Google drive root '': Waiting for transfers to finish
2020/12/10 13:36:28 DEBUG : Users/taccount/Dell Service Form.pdf: MD5 = 0328fd7c5af4451eca09f7a6ae63149d OK
2020/12/10 13:36:28 INFO  : Users/taccount/Dell Service Form.pdf: Copied (new)
2020/12/10 13:36:28 NOTICE: \\?\L:\Scans\Users\taccount\Dell Service Form.pdf: Remove detected sharing violation - retry 1/10 sleeping 1ms
2020/12/10 13:36:28 NOTICE: \\?\L:\Scans\Users\taccount\Dell Service Form.pdf: Remove detected sharing violation - retry 2/10 sleeping 2ms
2020/12/10 13:36:28 NOTICE: \\?\L:\Scans\Users\taccount\Dell Service Form.pdf: Remove detected sharing violation - retry 3/10 sleeping 4ms
2020/12/10 13:36:28 NOTICE: \\?\L:\Scans\Users\taccount\Dell Service Form.pdf: Remove detected sharing violation - retry 4/10 sleeping 8ms
2020/12/10 13:36:28 NOTICE: \\?\L:\Scans\Users\taccount\Dell Service Form.pdf: Remove detected sharing violation - retry 5/10 sleeping 16ms
2020/12/10 13:36:28 NOTICE: \\?\L:\Scans\Users\taccount\Dell Service Form.pdf: Remove detected sharing violation - retry 6/10 sleeping 32ms
2020/12/10 13:36:28 NOTICE: \\?\L:\Scans\Users\taccount\Dell Service Form.pdf: Remove detected sharing violation - retry 7/10 sleeping 64ms
2020/12/10 13:36:28 NOTICE: \\?\L:\Scans\Users\taccount\Dell Service Form.pdf: Remove detected sharing violation - retry 8/10 sleeping 128ms
2020/12/10 13:36:28 NOTICE: \\?\L:\Scans\Users\taccount\Dell Service Form.pdf: Remove detected sharing violation - retry 9/10 sleeping 256ms
2020/12/10 13:36:28 NOTICE: \\?\L:\Scans\Users\taccount\Dell Service Form.pdf: Remove detected sharing violation - retry 10/10 sleeping 512ms
2020/12/10 13:36:29 ERROR : Users/taccount/Dell Service Form.pdf: Couldn't delete: remove \\?\L:\Scans\Users\taccount\Dell Service Form.pdf: The process cannot access the file because it is being used by another process.
2020/12/10 13:36:29 ERROR : Attempt 1/3 failed with 1 errors and: remove \\?\L:\Scans\Users\taccount\Dell Service Form.pdf: The process cannot access the file because it is being used by another process.

Based on the error log you shared, it did not move the file.

If it's in use, it won't copy it.

No, it did. Yes, it didn't delete the original, but it DID upload a copy to Google Drive.

That means the file wasn't in use the time is being copied.

An example would be like this:

C:\Users\earlt\Downloads\rclone-v1.53.3-windows-amd64>rclone copy blah.txt GD: -vv
2020/12/10 14:05:14 DEBUG : rclone: Version "v1.53.3" starting with parameters ["rclone" "copy" "blah.txt" "GD:" "-vv"]
2020/12/10 14:05:14 DEBUG : Creating backend with remote "blah.txt"
2020/12/10 14:05:14 DEBUG : Using config file from "C:\\Users\\earlt\\.config\\rclone\\rclone.conf"
2020/12/10 14:05:14 DEBUG : fs cache: adding new entry for parent of "blah.txt", "//?/C:/Users/earlt/Downloads/rclone-v1.53.3-windows-amd64"
2020/12/10 14:05:14 DEBUG : Creating backend with remote "GD:"
2020/12/10 14:05:14 DEBUG : blah.txt: Need to transfer - File not found at Destination
2020/12/10 14:05:14 ERROR : blah.txt: Failed to copy: failed to open source object: The process cannot access the file because it is being used by another process.
2020/12/10 14:05:14 ERROR : Attempt 1/3 failed with 1 errors and: failed to open source object: The process cannot access the file because it is being used by another process.
2020/12/10 14:05:15 DEBUG : blah.txt: Need to transfer - File not found at Destination
2020/12/10 14:05:15 ERROR : blah.txt: Failed to copy: failed to open source object: The process cannot access the file because it is being used by another process.
2020/12/10 14:05:15 ERROR : Attempt 2/3 failed with 1 errors and: failed to open source object: The process cannot access the file because it is being used by another process.
2020/12/10 14:05:15 DEBUG : blah.txt: Need to transfer - File not found at Destination
2020/12/10 14:05:15 ERROR : blah.txt: Failed to copy: failed to open source object: The process cannot access the file because it is being used by another process.
2020/12/10 14:05:15 ERROR : Attempt 3/3 failed with 1 errors and: failed to open source object: The process cannot access the file because it is being used by another process.
2020/12/10 14:05:15 INFO  :
Transferred:             0 / 0 Bytes, -, 0 Bytes/s, ETA -
Errors:                 1 (retrying may help)
Elapsed time:         1.0s

2020/12/10 14:05:15 DEBUG : 4 go routines active
2020/12/10 14:05:15 Failed to copy: failed to open source object: The process cannot access the file because it is being used by another process.

seems that .pdf was copied to gdrive but rclone was unable to delete it.
could be a permissions issue with the user that rclone is running under.

But I had Adobe Acrobat open the whole time, not just during the time it wasn't copying it.

Adobe Acrobat was an example.. is there a native way Rclone can ignore a file for uploading until it's not being written to anymore?

I'd have to do more testing to see how exactly the MFPs write files to SMB share - if it caches it then transfers it, or directly writes to the file it saves to the share.

just because a file is in use with acrobat, does not mean that acrobat has the file open at any given moment.
acrobat, might open a file for edit, save a change and then close the file.

as a test, you might write a simple batch script to test it, running as the same user, that rclone runs as.

As a separate test, I had Adobe Acrobat open with that file and I tried deleting the file in the folder manually, in File Explorer, and it rejected it, saying that the file is open in a program. And it continues to do this, so it appears it is constantly opened with Adobe Acrobat in one way or another, maybe a way that Rclone ignores?

UPDATE: I tested scanning a document with 35 pages in a scanner, and had Rclone running the command every second. In the middle of the scanner writing, Rclone came up with an error saying something along the lines of:
"..source file is being updated. Size changed..."

Looks like the functionality I'm looking for is definitely there!!! :slight_smile: THANKS

No, those are two different things.

A file in use won't be copied because it has a lock.

A file can be opened / written to / closed and when rclone comes around it notices the size has changed mid transfer and stops.

It's up to the application to lock the file rather than opening and closing it.

You can test with opening notepad on a file as that doesn't lock the file.

If you copy a file and try to upload it, it would say in use.

That is a pretty good test. It isn't perfect though.

What you probably want is to include something like a --min-age 5m filter flag which won't attempt to sync things unless they are at least 5 minutes old.

That would be nice, but it is not ideal. We scan a lot of documents in, and the potential of people having to wait 5 minutes for their scans to appear in Google Drive is way too long. :confused:

make it --min-age 2m then

or scan directly to the cloud drive. Many newer MFP/scanning solutions support scanning directly to cloud storage - this would not require rclone.

Ah, I didn't realise you might have impatient users on the other end!

You can make the number smaller which might work well.. Does the scanner write the PDF all in one go at the end or does it write it while scanning each page? If the former then setting --min-age 15s might work provided it takes the scanner less than 15 seconds to save the file (which seems likely),

It appears the solution I have with Rclone is working correctly. It's been able to detect when the PDF is open and being modified, then works after the MFP is done with it. :slight_smile:

This post is solved.

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.