"Not enough space" error

Discuss new features and functions
Posts: 13
Joined: 19 Aug 2020

camner

I set up FFS in Update mode with versioning. On the second run, FFS threw this error:
Cannot write file "/Volumes/LR Managed Folders MPG BU/2014-09-24_MBG Snapshot 09-08-2018 Thu 11-45 AM/.sync.ffs_db.3e33.ffs_tmp".

ENOSPC: No space left on device [fcntl(F_PREALLOCATE)]


If I understand this message correctly, FFS found insufficient space on the SOURCE volume to create a temporary file. And yes, the source volume is essentially completely full.

Is there a way to have FFS store its temporary files on different volume than the source volume?
User avatar
Posts: 3607
Joined: 11 Jun 2019

xCSxXenon

You can't change where the tmp files are stored. The file is written to the destination with the 'tmp' appended to the end and then is renamed to the correct filename once the file is fully transferred to avoid corrupting the destination copy, if the transfer is interrupted. Doesn't matter anyway because FFS creates these ffs_tmp files wherever it is writing to, not reading from. Check your locations. Post a screenshot of the FFS window with your locations visible and the sync settings panel (all 3 tabs) if everything looks right to you, we can usually figure it out once we see that info.
Posts: 13
Joined: 19 Aug 2020

camner

Thanks for the quick reply and for the info about how FFS generates the tmp files.
As requested, the screenshots are attached.

The destination volume has 2.85TB free space (out of 3TB). I suspect the temporary file isn't bigger than that! :)
Attachments
synchronization tab
synchronization tab
2023-09-20_FFS-3.jpg (299.27 KiB) Viewed 1282 times
filter tab
filter tab
2023-09-20_FFS-2.jpg (206.58 KiB) Viewed 1282 times
comparison tab
comparison tab
2023-09-20_FFS-1.jpg (243.87 KiB) Viewed 1282 times
main window
main window
2023-09-20_FFS-0.jpg (568.54 KiB) Viewed 1282 times
Posts: 13
Joined: 19 Aug 2020

camner

As I continue to dig into this and observe what is happening, it seems that the copy job always fails at the very end. If I select "Ignore," the job ends and reports the error in the log. As far as I can tell, all files have been copied.

I've noticed that the temporary file that causes the error is always named something such as ".sync.ffs_db.3e33.ffs_tmp". The fact the filename contains "_db" suggests to me that it is the FFS database file that isn't being written out. So I disabled the option "Use database file to detect changes," and lo and behold, the copy job works perfectly and doesn't error out.

Where is the database file stored on the target location? It's an invisible file. I'm wondering if something is preventing the database file from being written out...

I'm running FFS on a Mac with MacOS 12.6.9. I have checked in System Preferences and FFS has been granted "Full Disk Access".
Posts: 13
Joined: 19 Aug 2020

camner

OK, digging even further. The FFS database file is stored on the SOURCE, not on the target, it seems. My first two runs ran perfectly, and then subsequent runs errored out with the "not enough space" message. Sure enough, if I look at the sources (they are folders, not an entire volume), the first two sources have the database file, but subsequent ones do not.

So, it seems that the issue is very much related to my source drive being full (the OS reports 8KB free!).

This is a conundrum. The source volume has a lot of hard links on it, and if I try to delete some folders on the source after copying them with FFS, this is going to really screw things up royally!
User avatar
Posts: 3607
Joined: 11 Jun 2019

xCSxXenon

Ok, I must have been tired when I first read your post! Yes, the sync.db file is written to the source and destination, which is why disabling "detect changes" fixes the issue. When you first said the source is "essentially completely full", you really should have said it is absolutely completely full LOL
The sync.db file keeps track of files that you rename or move into different folders so FFS doesn't have to delete and re-copy the data as if it is entirely new. You don't 'need' it, but it saves time since it isn't transferring the file(s) again. Your only options are to disable 'detect changes' and delete the hidden sync.db files to gain some space back, or obtain enough free space to use the feature by deleting data or getting a bigger source drive.
My biggest sync.db file is about 1MB, super small, and I was just assuming you had at least that much space :p
Posts: 13
Joined: 19 Aug 2020

camner

My biggest sync.db file is about 1MB, super small, and I was just assuming you had at least that much space :p xCSxXenon, 21 Sep 2023, 14:15
I DID have that much space, enough to save the DB file for 2 FFS runs (source = different folders). I didn't run out of the space until the 3rd run.

Thanks for all of your help. I think I have a good way forward now.