I have a Linux and a Windows Desktop and sync both via a Synology NAS via SMB.
For Linux, I created a .Trash-1001 folder and everything works fine. On Windows, I get a message, that a trash bin is not supported. I tried to create to .Trash-<my userid> folder, but that does not work. Is it possible to have a Trash Bin for the Windows client on my Synology?
When I use versioning and choose a folder on my Syno, where are the files be stored, that are deleted on Windows?
Don't understand Recylce Bin under Windows
- Posts: 5
- Joined: 23 Jul 2019
-
- Posts: 2453
- Joined: 22 Aug 2012
In Windows, the Recycle Bin (trash) is only available for local disks.
Any files deleted from the NAS will not end up in some (Windows) Recycle Bin.
How that works in Linux I don't know.
However, in a Synology NAS you can define per share if a NAS-based Recycle Bin is to be used.
( DSM > Control Panel > Shared Folder > (Select a folder) > Edit > Enable Recycle Bin )
Any files deleted from such a NAS share are moved to that share's Recycle Bin instead of permanently deleted (moved to /dev/null/).
But Windows is blissfully unaware of this NAS feature and (still) complains no trash folder is available.
If you use Versioning in FreeFileSync (FFS), all files that are "deleted" from the left and/or right location(s) in such FFS sync will be moved to the specified Versioning location, using the selected naming convention. As this "deletion" is effectively a "move", those files should not also end up in a Recycle Bin, wherever that may reside.
Any files deleted from the NAS will not end up in some (Windows) Recycle Bin.
How that works in Linux I don't know.
However, in a Synology NAS you can define per share if a NAS-based Recycle Bin is to be used.
( DSM > Control Panel > Shared Folder > (Select a folder) > Edit > Enable Recycle Bin )
Any files deleted from such a NAS share are moved to that share's Recycle Bin instead of permanently deleted (moved to /dev/null/).
But Windows is blissfully unaware of this NAS feature and (still) complains no trash folder is available.
If you use Versioning in FreeFileSync (FFS), all files that are "deleted" from the left and/or right location(s) in such FFS sync will be moved to the specified Versioning location, using the selected naming convention. As this "deletion" is effectively a "move", those files should not also end up in a Recycle Bin, wherever that may reside.
- Posts: 5
- Joined: 23 Jul 2019
Thanks for clarification. Then I have an enhancement request. When using Versioning, would it be possible to have two versioning locations, one on each side? And all files deleted on one side will go to the versioning location on that directory/drive. Then, moving to versioning would only be an OS move.
My use case is, that I often sync very large files over network. With only one versioning location, all deleted files one at least one side would need to be transferred over the network to the versioning location, which would cost much time.
This is my first enhancement request, is it enough to post it here?
My use case is, that I often sync very large files over network. With only one versioning location, all deleted files one at least one side would need to be transferred over the network to the versioning location, which would cost much time.
This is my first enhancement request, is it enough to post it here?
-
- Posts: 2453
- Joined: 22 Aug 2012
This post is drifting off-topic.
Nevertheless, posting feature requests here should be enough to trigger the author, but is by no means a guarantee that your request will be honored.
Personally, I don't see the problem.
Normally you run your syncs at quiet times, e.g. at night, when loading of the network should be less of an issue.
Additionally: indirectly you already have substantial control over network loading due to Versioning.
- If you run a left-to-right Mirror or Update sync, any deletion or replacement of files will always be from/in your right-side location. By defining your Versioning location to be also on that right-side network resource (e.g. NAS, server or computer) all Versioning related moves will then be local to that right-side location.
- If you run a Two-way sync, and deletions or replacements may originate at both ends, simply define your Versioning location at the network-resource side where user initiated deletions or replacements are less/least likely to originate. Then most of the Versioning related moves will be local.
Also: be aware that having a Versioning location per side, means that, when looking for a previous version, you need to know where any deletion or replacement of a file originated, and then look in the opposite Versioning location ... In my view far from ideal in both said aspects.
Nevertheless, posting feature requests here should be enough to trigger the author, but is by no means a guarantee that your request will be honored.
Personally, I don't see the problem.
Normally you run your syncs at quiet times, e.g. at night, when loading of the network should be less of an issue.
Additionally: indirectly you already have substantial control over network loading due to Versioning.
- If you run a left-to-right Mirror or Update sync, any deletion or replacement of files will always be from/in your right-side location. By defining your Versioning location to be also on that right-side network resource (e.g. NAS, server or computer) all Versioning related moves will then be local to that right-side location.
- If you run a Two-way sync, and deletions or replacements may originate at both ends, simply define your Versioning location at the network-resource side where user initiated deletions or replacements are less/least likely to originate. Then most of the Versioning related moves will be local.
Also: be aware that having a Versioning location per side, means that, when looking for a previous version, you need to know where any deletion or replacement of a file originated, and then look in the opposite Versioning location ... In my view far from ideal in both said aspects.
- Posts: 5
- Joined: 23 Jul 2019
Sorry for late reply, just found the notification in my spam folder.
My use case is:
- I don't sync at night, but on demand when I have changed something important.
- I sync very big media files and lots of them, so even in a fast network, transfer volume is an issue.
- sometimes the other side would not have the space to take back the deleted files.
- Sometimes I sync two servers via client, so that would be double the network traffic. From server 1 to the client, then from the client to server 2, right?
- I got your points, and my request is probably not the best choice for anyone. But maybe the default would stay as is and my request could be an extra option?
- I have used GoodSync for years, but trying FFS now because GS does not support Linux. But GS works that way with local trash bins and that worked better for my case.
So what I do today is to run a compare to see differences, then log on to the according server and manually do deletes or move the files to a bin and only sync the smaller files. I would be glad to skip the manual steps. Does this make sense somehow?
My use case is:
- I don't sync at night, but on demand when I have changed something important.
- I sync very big media files and lots of them, so even in a fast network, transfer volume is an issue.
- sometimes the other side would not have the space to take back the deleted files.
- Sometimes I sync two servers via client, so that would be double the network traffic. From server 1 to the client, then from the client to server 2, right?
- I got your points, and my request is probably not the best choice for anyone. But maybe the default would stay as is and my request could be an extra option?
- I have used GoodSync for years, but trying FFS now because GS does not support Linux. But GS works that way with local trash bins and that worked better for my case.
So what I do today is to run a compare to see differences, then log on to the according server and manually do deletes or move the files to a bin and only sync the smaller files. I would be glad to skip the manual steps. Does this make sense somehow?
-
- Posts: 2453
- Joined: 22 Aug 2012
Your use case seems very specific and may require a solution that may indeed be "probably not the best choice for anyone"
> Sometimes I sync two servers via client, so that would be double the network traffic. From server 1 to the client, then from the client to server 2, right?
Correct. When running FFS on a machine that is hosting the left nor right base location, FFS does not/ can not initiate direct file-transfers between the left and right location or vice-versa. But that applies generally to all file transfers in such application conditions, not only to Versioning related file transfers.
In that sense, and particularly in your use case, it may be better to, if possible, run FFS on either of your two servers.
> Sometimes I sync two servers via client, so that would be double the network traffic. From server 1 to the client, then from the client to server 2, right?
Correct. When running FFS on a machine that is hosting the left nor right base location, FFS does not/ can not initiate direct file-transfers between the left and right location or vice-versa. But that applies generally to all file transfers in such application conditions, not only to Versioning related file transfers.
In that sense, and particularly in your use case, it may be better to, if possible, run FFS on either of your two servers.
- Posts: 5
- Joined: 23 Jul 2019
My servers are running without UI, so unfortunately this is no option for me. These are systems like a Synology NAS and a LibreElec on Raspi. Maybe this is use case is specific to me. On the other hand, local trash bins are for example the default in GoodSync, which is also a popular sync tool. And when deleting manually on a file system, probably many would expect the deleted files in the trash bin of that drive.
But no matter what the best default would be: would'nt this make a reasonable enhancement request to have at least the extra option to version all files locally?
It should not be too much coding effort to move deleted files to a local folder instead of a remote one, and it would make FFS even more versatile.
But no matter what the best default would be: would'nt this make a reasonable enhancement request to have at least the extra option to version all files locally?
It should not be too much coding effort to move deleted files to a local folder instead of a remote one, and it would make FFS even more versatile.
