View Issue Details

IDProjectCategoryView StatusLast Update
0000259VisualDifferFolders differpublic2015-06-14 05:16
Reporteriu3246 Assigned Toadmin  
PrioritynormalSeverityminorReproducibilityalways
Status assignedResolutionopen 
PlatformMacOSYosemiteOS Version10.10.3
Product Version1.6.3 
Summary0000259: Copy issues after NAS drive firmware update
DescriptionI use VisDiff to sync various backups on external drives. After a Drobo 5N firmware update, I have had various issues using VisDiff to copy files. Some folder names were lost on the Drobo and seem to have a random string of letters. I was using less than < and greater than > symbols in file names which copies okay. Closing VisDiff and rerunning the compare shows a mismatch on the filenames. I stopped using the < and >. Apparently, Drobo NAS looses some of the attribute info when copying from a regular Mac folder.

After copying any new or updated file to the NAS folder, it copies normally. A subsequent fresh compare shows a new hidden file starting with "._filename.ext" which is always a size of 4096. The printable info in this file contains:
"Mac OS X 2 ATTR com.apple.quarantine 0002;55650761;VisualDiffer; This resource fork intentionally left blank "
Steps To ReproduceCopy a new file to Drobo NAS. Close and rerun the compare. The "._filename.ext" shows as an orphan.
Additional InformationI have been deleting the hidden "._filename.ext" files. I'd like to understand what is going on. Is there a setting that will help?

I remember a similar problem many versions ago with VisDiff and an older Drobo firmware. I'd like to just go back to the older Drobo firmware but it is not available.
TagsNo tags attached.

Activities

admin

2015-05-27 17:19

administrator   ~0000540

Last edited: 2015-05-27 17:20

Reproducing the problem is very difficult because I haven't a drobo NAS.

VD uses standard Apple calls to copy/move files so I don't understand where is the problem.

VD doesn't write "._filename.ext" file, In some manner do you share files with MS Windows? Under Windows resource forks can be broken.

May you reproduce the problem with only few files (3-4 files)?
Copy the same files from Finder does work fine?

iu3246

2015-05-27 19:53

reporter   ~0000541

Okay, I'll try the copy with Finder later. My internet was down all morning.
I still think the Drobo firmware is to blame but wondered if I could tweak VisDiff.

iu3246

2015-05-27 19:57

reporter   ~0000542

I don't have MS Windows. I have an ancient Parallels version with Win XP that I had before getting a Mac. I stopped updating Parallels since I don't need Windows.

admin

2015-05-28 17:38

administrator   ~0000543

I think something is wrong with VD but the code is so simple, I call the standard Apple APIs to copy/move files, no special handling, the copy is done one file at time (and this will be improved in future versions), no multiple async copy.

I've asked about Windows because when a NAS disk is shared between Windows computers and mac some files are badly handled from Win side, but this isn't your case

iu3246

2015-05-29 05:20

reporter   ~0000544

I sent Drobo support a diagnostic file. They sent me a link to reinstall the previous firmware. Unfortunately, that means essentially resetting or wiping the Drobo drive and repopulating it. I can try a few other things before that.

Instead of VisDiff, I can set up a copy using Carbon Copy Clone 4 and see if I have similar problems.

Sometimes I think the Drobo drive is not being recognized after computer went to sleep. VisDiff can't find the Drobo folder. I go to Finder and browse the share folder and then restart VisDiff compare and it will work.

iu3246

2015-05-29 20:57

reporter   ~0000545

I tried manual copies via Finder this morning for 2 directories. The extra hidden error files showed up in one but not the other. I restarted the Drobo. It takes some time for VisDiff to work with my saved compare. I had to start a manual compare and then the saved one worked. I noticed the compares where not the same. One displayed a slightly different share directory with a few different files. I then noticed that my computer finder folder showed 2 copies of the share folder mounted. The volumes mac folder only showed an AppleShare mount. The other folder showed a SMB mount. For some reason, when I create a new compare in VisDiff and select from my iMac computer, it shows 12 share folders of the same name. I may have to reboot to clear that. VisDiff only shows one share folder under Volumes so I don't understand the other list. I do still have 2 compare windows open (that show different trees).

iu3246

2015-05-29 20:59

reporter   ~0000546

I don't really understand the share mounting. Drobo has a window that will mount the shares. Apple Mac OS probably mounts the share volume also. I can probably disable the Drobo mount. I'll keep posting my progress...

admin

2015-05-31 17:53

administrator   ~0000547

I'm trying to reproduce the problem with a "simulated nas" (just a disk connected via network) and I would know if you access to drobo using a normal windows share folder (aka samba protocol)

iu3246

2015-05-31 20:18

reporter   ~0000548

Is "samba" what the SMB server mount is? On the info for the NAS drive it has for format: SMB (NTFS). Before I open VisDiff, all that I see is the SMB mount. After creating a new compare with the SMB mount, another mount appears for AFP server with format AppleShare. The saved compare will then be able to run. I'm thinking that having SMB and AFP mounts for the same volume names is causing the problems that I see. These point to the same files but the SMB doesn't seem to handle some of the names. The Drobo Dashboard app shows the share volumes. I can uncheck my NAS user folder and the SMB mount disappears. I don't know why but the Mac OS mounts the AFP AppleShare user folder. I don't remember setting up my share folder for either mount type. I created my user share in the Drobo Dashboard a couple+ years ago. Somehow, I was using AFP version in VisDiff. I could have had the SMB mount unchecked but installing the new firmware rechecked the box.

iu3246

2015-06-10 19:53

reporter   ~0000549

Drobo support mentioned that firmware updated the Samba version. I went back to the old firmware and had to repopulate the Drobo drive. I made sure to mount the user share with Apple File share ONLY. I haven't seen the problem since. I may retry the firmware update but try not to use the SMB mount. However, I need to reconsider whether I need the SMB mount to run Drobo drive apps such as Plex which I suspect may need a SMB mount directory. I'm in no hurry to try it immediately.

admin

2015-06-11 17:50

administrator   ~0000550

I'm pretty sure OSX SMB implementation isn't perfect, I've found tons of bugs for example the modification date not correctly updated, VD uses a workaround to fix it.

Plex uses SMB, Kodi too, I hope Drobo fixes the problem when you will need to use Plex.

So, this time I suspect VD isn't guilty but the mix AFP/SMB, do you agree?

iu3246

2015-06-14 05:16

reporter   ~0000551

I think I agree with that. I just don't want to go back and test it. It did seem to cause folder and file name differences. Before, the share was auto mounted when the Drobo booted up. The new Dashboard update was likely a factor too since it is the UI that does the mounting. I may need to revert to the older Dashboard but it's probably better to mount using Mac OS.

Issue History

Date Modified Username Field Change
2015-05-27 02:36 iu3246 New Issue
2015-05-27 02:36 iu3246 Status new => assigned
2015-05-27 02:36 iu3246 Assigned To => admin
2015-05-27 17:19 admin Note Added: 0000540
2015-05-27 17:20 admin Note Edited: 0000540
2015-05-27 19:53 iu3246 Note Added: 0000541
2015-05-27 19:57 iu3246 Note Added: 0000542
2015-05-28 17:38 admin Note Added: 0000543
2015-05-29 05:20 iu3246 Note Added: 0000544
2015-05-29 20:57 iu3246 Note Added: 0000545
2015-05-29 20:59 iu3246 Note Added: 0000546
2015-05-31 17:53 admin Note Added: 0000547
2015-05-31 20:18 iu3246 Note Added: 0000548
2015-06-10 19:53 iu3246 Note Added: 0000549
2015-06-11 17:50 admin Note Added: 0000550
2015-06-14 05:16 iu3246 Note Added: 0000551