Getting EEXIST out of make_bak_dir()
mike at bombich.com
Wed Mar 10 07:54:16 MST 2010
On Mar 9, 2010, at 10:09 AM, Wayne Davison wrote:
> On Mon, Mar 08, 2010 at 10:02:26AM -0600, Mike Bombich wrote:
>> rsync: make_bak_dir mkdir "/Volumes/Backup/_Archive_2010_March_07_22-27-43/Users/jsmith/Library/Mail/Mailboxes/ Orchestra" failed: File exists
> Is something else creating that directory at the same time? A race
> where 2 processes are creating the same directory would be pretty rare,
> though, so it makes me think that OS X is really failing with the wrong
> error for a filename it doesn't like. I note that the next element has
> an asterisk in it -- should that work OK on that filesystem?
An asterisk is fine but I thought it might raise eyebrows, that's why I added the second user example which didn't have any questionable characters.
>> rsync: keep_backup failed: "/Volumes/Backup/Users/jsmith/Library/Mail/Mailboxes/ Orchestra/ * New Mexico Concert/Assistant - John Smith.mbox/Messages/269981.emlx" -> "_Archive_2010_March_07_22-27-43/Users/jsmith/Library/Mail/Mailboxes/ Orchestra/ * New Mexico Concert/Assistant - John Smith.mbox/Messages/269981.emlx": No such file or directory
> Note that this error is for the backup -- since the full path does not
> exist, trying to create the backup file returns the ENOENT error.
>> if (mkdir_defmode(fbuf) == 0 || errno == EEXIST) // <-- Trap for EEXIST?
> The reason I hadn't done that before was because EEXIST gets returned
> for any file type -- e.g. file or dir. But this should be OK for the
> make_bak_dir() function because it will always be followed up with
> either another mkdir() or an attempt to use the path, which should fail
> with ENOTDIR if it momentarily accepts a non-dir. You might try the
> attached patch and see if it helps.
Thanks, that patch matches what I've seeded with a couple users. I'll spread my patch to a few more affected users and let you know if it resolves the issue.
More information about the rsync