cwRsync ignores "nontsec" on Windows 7 - windows-7

I use cwRsync to sync up some file from Windows to Ubuntu. This process used to work fine on Vista, but since I upgraded to Windows7, I keep getting permission issues.
Some background... I did use to get the same permission issues on Vista, but that was resolved by using the CYGWIN=nontsec environment variable.
The premission problem
rsync: failed to modify permissions on xxx: Permission denied (13)
Since windows and UNIX file permissions differ, sync'ing files with windows permissions doesn't make sense. What rsync does is set the permission on the UNIX side to 0 (d---------). To prevent this, cygwin has the nontsec variable which instructs it to ignore the windows file permissions.
The problem is, on Windows7, nontsec appears not to have any effect.

re your solution, I had to make an adjustment to see it work for me - instead of your etc/fstab content, I used this content from the forum topic you reference:
none /cygdrive cygdrive binary,posix=0,user,noacl 0 0
I'm using cwRsync installer 4.0.3. I'm happy enough that it works for me but I can't offer a reason why, not being familiar enough with fstab syntax and options. Hopefully it adds something useful to someone else.

I figured out that it wasn't Windows 7 that was causing the issue. Rather, it was the new version of cwrsync that was ignoring the nontsec environment var. For cwRsync versions higher than 1.7, you need to use the noacl option. (see forum topic: No access to subfolders of RSYNC backup folder)
The solution involves creating an fstab file with the noacl option:
# In this example, my cwRsync dir is located at: "C:/Program Files (x86)/cwRsync"
# Filename: "C:/Program Files (x86)/cwRsync/etc/fstab"
C:/Program\040Files\040(x86)/cwRsync / ntfs override,binary,noacl 0 0
C:/Program\040Files\040(x86)/cwRsync/bin /usr/bin ntfs override,binary,noacl 0 0
And that's it! You can also remove the CYGWIN=nontsec env var since it's no longer used.

I was having this same problem copying from my Solaris based webhost down to my local PC. The PC permissions were wacked when the files were copied down. I setup the fstab file but no go.
In the end I realized that I was making a full path call to rsync.exe which meant my current directory was no picking up the etc folder I just created. To resolve this, I added these lines just above the call to the rsync command and it worked perfectly.
SET CWRSYNCHOME=%PROGRAMFILES%\CWRSYNC
c:
cd %CWRSYNCHOME%
Now my file permissions are correctly defaulting to the parent folder permissions without issues.
I just wanted to tag this onto this thread in case anyone else in the future is coming across the same issue I was.

This is now also addressed in the cwrsync FAQ:
http://www.itefix.no/i2/node/11324
I can also report the fix in the FAQ (and Raise's answer) worked for me as well.

I had the same problem, but none of the solutions worked for me, until I realized my destination folder was outside the rsync folder. (I wanted to rsync files from Linux to Windows.)
Here is what worked for me:
Create a subdir etc inside the cwRsync folder (that is, where the rsync.exe resides).
Create a file named fstab (no suffix) inside that folder.
Insert one line into that fstab file, be sure to have UNIX line endings!
none /cygdrive cygdrive binary,posix=0,user,noacl 0 0
Set environment:
SET CWRSYNCHOME=<cwRsync installation path>
SET HOME=<Directory to save user configuration files, like ssh known_hosts>
Before starting rsync.exe (this was the most important step in my case):
cd <Destination folder>
The SET HOME part is important for SSH, it will create a .ssh subfolder there with a known_hosts file.

Related

Creating folders in Cygwin results in incorrectly ordered permissions, failure to open files

This is something recent with my Cygwin on Win 10. If I do "mkdir folder", then in Windows, checking folder properties and selecting the Security tab gives the popup: The permissions on folder are incorrectly ordered, which may cause some entries to be ineffective.
If I then create a file in that folder from Windows, in order to open that file, I have to first remove one of the permissions entries under Properties>Security>Advanced for that file. That entry indicates "deny special access for the owner of the file".
What is causing incorrect ordering of permissions and also what I believe is the wrong permissions to be assigned to newly-created folder in Cygwin?
Source: Forcing Cygwin to create sane permissions on Windows
Adding the noacl option to this file worked for me on Windows 10 Home with Cygwin x64:
CYGWIN_NT-10.0 3.1.6(0.340/5/3) 2020-07-09 08:20 x86_64 Cygwin
You may need to find where your Cygwin folder is located.
File:
C:\cygwin64\etc\fstab
Contents:
# /etc/fstab
#
# This file is read once by the first process in a Cygwin process tree.
# To pick up changes, restart all Cygwin processes. For a description
# see https://cygwin.com/cygwin-ug-net/using.html#mount-table
# This is default anyway:
none /cygdrive cygdrive binary,noacl,posix=0,user 0 0
After changing the fstab file I had to reboot my PC.
Also, when I used rsync I passed these arguments:
time rsync -avh --delete --progress --chmod=ugo=rwX /cygdrive/s/source/ /cygdrive/d/destination/

Windows - hard links to files in a git repository break often

I maintain a private Git repository with all of my config and dotfiles (.bashrc, profile.ps1, .emacs etc.).
On Windows this repository is stored under C:\git\config. Most applications expect the files to be elsewhere, so I added hard links between the repository and the expected locations.
Example
On Linux .emacs is located in ~/git/config/.emacs but emacs expects it to be at ~/.emacs. I run:
$ sudo ln -s ~/git/config/.emacs ~/.emacs
On Windows my .emacs is located in C:\git\config\.emacs, but emacs expects it to be in C:\users\ayrton\.emacs. I run:
PS> cmd /c mklink /H C:\users\ayrton\.emacs C:\git\config\.emacs
Issue
On Linux this seems to work fine: when I update the original file, the contents of the link update and everything stays in sync.
On Windows, the links break after a period of time and the files become out of sync (the file contents are different).
Why do the links break on Windows? Is there an alternative solution?
I've seen this StackOverflow post: Can't Hard Link the gitconfig File
So I’ve finally found a solution that takes the best of both: put the repo in a subdirectory, and instead of symlinks, add a configuration option for “core.worktree” to be your home directory. Now when you’re in your home directory you’re not in a git repo (so the first problem is gone), and you don’t need to deal with fragile symlinks as in the second case. You still have the minor hassle of excluding paths that you don’t want versioned (eg, the “*” in “.git/info/exclude” trick), but that’s not new.
The problem here is that the expected locations are different on Windows vs. Linux. For example, VSCode expects the user settings to be in:
Linux: $HOME/.config/Code/User/settings.json
Windows: %APPDATA%\Code\User\settings.json
Ideally I would like my repository to be platform independent. If take the core.worktree approach (e.g. make core.worktree be / or C:\, then exclude everything except specific files) I would have to maintain two copies of some configuration files when their absolute paths differ across operating systems.
Hardlinks can break if a editor opens/creates the file as a new blank file each time you save. It would not surprise me if Notepad did this because it reads the entire file into memory and has no need for the original file after it has loaded the file.
You can try to create a file symlink instead of hardlink on Windows.

Why are files created in git bash not visible in Windows explorer?

So I just moved from Ubuntu to Windows (read forced to move, thanks to compatibility issues) and am using Git Bash to pull in my files. I've noticed something extremely strange.
Git Bash is installed in C:\Program Files (x86)\Git\, and when I first run the Git Bash program, the default location is this. Normal right? Right.
But here's the weird part..
When I run the command mkdir srv in the Git Bash command line, I can see it in the Bash window - but I can't see it in Windows Explorer?! What the heck. Same thing happens with files created using vi in the CLI. Invisible in Windows Explorer. (Yes, I have enabled the Show hidden files option in Explorer, so it's not that).
Here are some snapshots (no, I'm not blind - nor am I insane). Help?
You might not be able to see the folder because of missing privileges. Try running your explorer as Administrator and look again.
The proposed solutions above didn't help me. However, I copied the hidden directories to another place via git bash. Then I copied them once again via windows explorer to the original place. Now they've become visible. I created those invisible folders via git bash with git clone command before.
I had similar issue, but with file attributes, not with missing privileges.
In cmd under C:\Program Files (x86)\Git\ run command attrib
attrib *
You will know if srv folder has System or Hidden file attribute.
If you would like to view it in cmd then use dir /a:s

rsync from Linux to Windows 7 creates files that I do not have permission to access

I'm using rsync under cygwin to synchronize my music and pictures folders across two machines. I have full control over both of these folders on the Windows machine, and the permissions on the Linux machine are generally -rw-------, owned by me. When I use, for example, rsync -rvu --delete rsync://fraxtil#linuxmachine:/music/ /cygdrive/d/Music/, it creates the files and folders in D:\Music\, but I don't have permission to access them, and as a result rsync fails to recurse into newly created directories.
I've tried adding --chmod=a+rwx,g+rwx,o+rwx to the command, adding noacl to cygwin's fstab entry for /cygdrive/, and removing read only = yes from Linux's rsyncd.conf, but none of these solved the issue.
My rsyncd.conf:
log file = /var/log/rsync.log
timeout = 300
[music]
comment = Music
path = /home/fraxtil/music
#read only = yes
list = yes
uid = fraxtil
gid = fraxtil
auth users = fraxtil
secrets file = /etc/rsyncd.secrets
[pictures]
(mostly the same as above)
cygwin's /etc/fstab:
none /cygdrive cygdrive noacl,binary,posix=0,user 0 0
I've noticed that when I browse D:\ from bash under cygwin, most of the files have mode 0200 or 0000. This might be related to my problem. However, the newly created files, oddly enough, have mode 0270, which is baffling because those are the ones I can't access, yet they have more permissions.
Any ideas?
This was originally posted as an edit to my original question, but now that another answer exists I need to accept something to keep my 100% accept rate:
I just removed the --chmod bit from the rsync command and now I have the proper permissions again. I had tried --chmod with noacl and no --chmod with acl, but hadn't yet tried no --chmod with noacl. The lattermost works for me. I'll leave this open if anyone wants to explain why this happens the way it does.
Thanks for the solution.
I was stucked in rsyncing between a disk, and a USB disk.
rsync created stranged NTFS permissions on folder too.
Adding --chmod=a+rwx,g+rwx,o+rwx allow me to rsync locally.
Final command is :
rsync -rv --delete --exclude "Dropbox/" --chmod=a+rwx,g+rwx,o+rwx /cygdrive/d/source /cygdrive/h/destination

Rsync bash script and hard linking files

I am creating a bash script to backup my files with rsync.
Backups all come from a single directory.
I only want new or modified files to be backed up.
Currently, I am telling rsync to backup the dir, and to check the files compared to the last backup.
The way I am doing this is
THE_TIME=`date "+%Y-%m-%dT%H:%M:%S"`
rsync -aP --link-dest=/Backup/Current /usr/home/user/backup /Backup/Backup-$THE_TIME
rm -f /Backup/Current
ln -s /Backup/Backup-$THE_TIME /Backup/Current
I am pretty sure I have the syntax correct for this. Each backup will check against the "Current" folder, and upload only as necesary. It will then delete the Current folder, and re-create the symlink to the newest backup it just did.
I am getting an error when I run the script:
rsync: link "/Backup/Backup-2010-08-04-12:21:15/dgs1200series_manual_310.pdf"
=> /Backup/Current/dgs1200series_manual_310.pdf
failed: Operation not supported (45)
The host OS is running HFS filesystem, which supports hard linking. I am trying to figure out if something else is not supporting this, or if I have a problem in my code.
Thanks for any help
Edit:
I am able to create a hard link on my local machine.
I am also able to create a hard link on the remote server (when logged in locally)
I am NOT able to create a hard link on the remote server when mounted via afp. Even if both files exist on the server.
I am guessing this is a limitation of afp.
Just in case your command line is only an example: Be sure to always specify the link-dest directory with an absolute pathname! That’s something which took me quite some time to figure out …
Two things from the man page stand out that are worth checking:
If file's aren't linking, double-check their attributes. Also
check if some attributes are getting forced outside of rsync's
control, such a mount option that squishes root to a single
user, or mounts a removable drive with generic ownership (such
as OS X's “Ignore ownership on this volume” option).
and
Note that rsync versions prior to 2.6.1 had a bug that could
prevent --link-dest from working properly for a non-super-user
when -o was specified (or implied by -a). You can work-around
this bug by avoiding the -o option when sending to an old rsync.
Do you have the "ignore ownership" option turned on? What version of rsync do you have?
Also, have you tried manually creating a similar hardlink using ln at the command line?
I don't know if this is the same issue, but I know that rsync can't sync a file when the destination is a FAT32 partition and the filename has a ":" (colon) in it. [The source filesystem is ext3, and the destination is FAT32]
Try reconfiguring the date command so that it doesn't use a colon and see if that makes a difference.
e.g.
THE_TIME=`date "+%Y-%m-%dT%H_%_%S"`

Resources