Jump to content

bpbpbp

Member
  • Posts

    18
  • Joined

  • Last visited

Posts posted by bpbpbp

  1. 11 minutes ago, Tolu said:

    Could you please elaborate on what you need to change per-project?

    >> Hi Tolu! Thanks for the response.  Perhaps I misunderstood the VWX prompt that came up when I changed a Mac's file share method from AFP to SMB - VWX said 'Project Sharing is configured to use AFP not SMB'... or similar, and it would not open the project when only SMB connections were made. I will have to test again tomorrow.
    If we move form AFP to SMB, I must anticipate 50 users seeing the message and not knowing what to do. I would prefer it if they saw no message at all.

     

    11 minutes ago, Tolu said:

     

    A file that has references does not store the protocol used to connect to the share or NAS device. The file stores the path.

    On Mac, the path is similar to this: /Volumes/ShareFolder/path/to/source.vwx

    On Win, the path is similar to this: \\Server\ShareFolder\path\to\source.vwx

     

    As such, you switching from AFP to SMB does not require any changes to the File. 

     

    Side note: The Mac allows you to mount a shared folder in multiple ways. For example, if the admin has shared a file at smb://OurServer/SharedFolder/WGR/File.txt. On the Mac, I can mount the Share in multiple ways (using Cmd+K). I can mount it as "smb://OurServer/SharedFolder/" or as "smb://OurServer/". Essentially, a user is allowed to specify his/her mounting point. The different mounting points will result in different paths to the text files. For the first mount, the path will be /Volumes/WGR/File.txt. The path to the 2nd mount will be /Volumes/SharedFolder/WGR/File.txt. If the text file was a vwx, you could imagine how specifying different mounting point will prevent the target file from automatically finding the source file. You can get around this issue by making sure all users on the team use the same mounting point, or you can use relative paths. With relative paths, VW will neglect the mount point. The only requirement when using relative paths is that the source and target file must be on the same volume.

     

    I don't know about your NAS device, so I can't speak about what you've experienced. In our tests, we have only found that when you connect to a Synology NAS device using different protocols, the file locks (read and write (R/W) locks) are not respected. That is, if a user opens a file for R/W using SMB, another user can open the same file for R/W using AFP. This error is why we strongly recommend using only one protocol. We have never seen the case where two different users using the same protocol is allowed to open the same file simultaneously. If you have a reproducible example, I will be glad to set up a screen sharing session to see what is happening.

     

    It is essential to point out that a user can connect to the same share using SMB and AFP at the same time. You should "Get File Info" (Cmd+I) on the file through the Finder window to see the protocol in use.

     

    Thanks,

    Tolu 

    Vectorworks Inc.

     

     

    Again, with a Mac that has only SMB shares connected, we opened an existing project and it gave the message that it could not be opened because Project Sharing was configured with AFP, not SMB...   if the protocol is not stored, then something else in VWX is giving me another issue t resolve 🙂

  2. Hi,

     

    I am planning a project to simplify a mixed Windows 10 & Mac Mojave office environment by switching off AFP so that only SMB is used to connect to our NAS.

     

    The only outstanding (application-independent) issue encountered so far is when a (Mac/Win) user has a file open, a computer running the other operating system does not see/respect the open file lock and allows the same file to be opened/modified - resulting in app crashes and sometimes file corruption…

     

    Vectorworks 2019 is fine if all Project Sharing master files are changed from AFP to SMB, but this has to be done manually on a per-project basis, and we have hundreds of projects. 

    I’m concerned about how projects reference materials, in-document links to other file locations, etc, if AFP were turned off one morning!

     

    - Has anyone any experience of a similar environment/project?

    - Is it possible to update all VW2018 & 2019 projects at once via a utility app?

    - Am I always going to face file access issues between OSX and Windows?  😞

     

    I also have to investigate Rhino 5...

     

    Thanks!

     

  3. Hi,

     

    We run our VW License Server software on a Windows 10 VM, hosted on an OSX Mac Mini with USB License Dongle attached.

     

    If the WINDOWS VM crashes, or the OSX mac, everything comes back up ok or via remote assistance, except for the USB dongle. It is not recognised until it is removed and re-inserted manually. This requires physical presence in the Server Room.

     

    #1 - Does anyone also see this issue on a native Windows PC? If not, I will look into installing Windows 10 on the Mac Mini or another small PC.

    #2 - Does anyone know a way to remotely 'reseat' a USB dongle?!

     

    Thanks!

    Benjamin

  4. We have a fresh install of VW2018 SP6 on Mac OSX High Sierra. It is no different to other computers in our company that can borrow licenses ok. This one, unfortunately, gives an error message when trying to borrow a license - whilst connected directly/locally to our office internal network (same subnet as license server):

     

    'Can't acquire a license from the server for the following modules: Fundamentals, Architect, Renderworks. Your server doesn't support these modules for this copy of Vectoworks or all licenses are in use'.

     

    We have plenty free licenses available. An identical device can borrow a license no problem at all. Same internal license server, same VW serial, etc. The user profile is an administrator of the laptop. Another local user account also gets the same error.

     

    I'm stumped!

    vwborrowerror.png

  5. Hi!

     

    We have a mixed Mac & PC environment, and all machines share the same Synology Server folder lcoations for each project. 
    When references are made on a Mac, the format is not recognisable on a PC (see attached screenshot) and vice versa.

    Therefore references are broken.

     

    Is there a know solution to this?


    I found this article regarding 'Workgroups' but the text is ambiguous; is it referring to the Windows Networking concept of a workgroup (as opposed to a domain) or is it a VW-only feature?

    http://app-help.vectorworks.net/2017/eng/VW2017_Guide/Workgroup/Workgroups_and_Referencing.htm

    I am not sure it will resolve the issue in any case.


    Thanks!

    VW_Ref_PC.png

  6. 5 minutes ago, Jim Wilson said:

    There should be no issue with having both on the same machines. It should be ensured that the last 6 of the serial numbers on each machine used for 2018 correspond to the last 6 used on those machines for 2019, so you don't get multiple machines thinking the same license is in use because a different version of the same license is running somewhere else.


    Thanks Jim! Our supplier say we can have an extra set of license for VW2019 and run them parallel with VW2018 on our internal license server, for 3 months FOC.

  7. Hi,

     

    This is my first post here. We have a network license for a number of Macs running latest release OSX High Sierra and VectorWorks 2018 SP4.

     

    Two users have a similar issue that I have verified. They open a network VW file (Synology NAS with Open Directory authentication) from Finder and work in it. They then save it with the Save/Close dialogue on exit, or command+S, and report that to me that the changes are not saved. What is actually happening, is that the documents are being saved to a local folder on their desktop - one that they have used previously, to save docs in a number of different applications, but not VW.

     

    To reproduce the issue, I opened an example network VW file, and selected File > Save As... It showed the correct network folder that I opened it from. But when I closed the file and chose Save, it actually saved it to the same local folder as previously reported. 

     

    The workaround solution at present is for all users to select 'Save As'.

     

    I'm keen to know if anyone has experienced anything similar?

     

    Thanks,

    Benjamin

×
×
  • Create New...