1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

File Saving/Organizing Question

Discussion in 'General Discussion' started by jfleming, Jul 17, 2020.

  1. jfleming

    jfleming Senior Member

    Quick/Easy one...

    Can I copy and paste an entire folder from one directory to another without issues? Or is a "Save As" required??

    Friday Brain not functioning, sorry.
  2. simonb65

    simonb65 Alibre Super User

    Save As or Package things up then un-package. Don't just copy and Paste it will mess up all your internal links and if it is a copy, you'll end up with duplicates unique ID's for parts which will really mess you up!
  3. JST

    JST Alibre Super User

    Package is handy if you are moving or duplicating a finished design. Since you only get the actually used parts, it is not ideal for moving the work directory if you still have work to do.

    Duplicated parts will be an issue for Alibre until (and unless) we get a functional true protected library, AND true "work directories" that are the universal default for saves and fetches.
    jfleming likes this.
  4. jfleming

    jfleming Senior Member

    Thanks, that's what I thought.
  5. Lew_Merrick

    Lew_Merrick Alibre Super User

    Hi Jason -- Though not recommended, you can use the Windows Explorer to copy Alibre Design files from one location to another. But you will need to open each file in the new location and perform a SaveAs with Overwrite to get Alibre to recognize it as existing in the "new location." It is often simpler to perform an entire series of SaveAs steps to move such files. -- Lew
  6. NateLiqGrav

    NateLiqGrav Alibre Super User

    We have been through this before.
    Copy Paste in Windows WILL CAUSE PROBLEMS eventually unless you follow a very specific work flow to fix the issues.






    @Max I can't find any of this in the Alibre Design Help file. This information MUST be added and emphasized. New users have no idea and cause themselves many problems.
    jfnewman, dlaery and jfleming like this.
  7. Drutort

    Drutort Senior Member

    If you have a fancy structure system and or doing work with many others, and files are on a server then all the below what I am going to say is not going to work

    Now if the structure is setup that you could somehow duplicate the file paths and/or at least have some of the files in the same locations then you could move around with your work, but still that would create so much headache, very prone to issues too

    But if you have a simple structure and do not mind to have duplicates of some files then:

    IMO, as long as you do not have any parts that go out of the parent project folder you are fine, but if you are using hardware and things reference out of parent project folder, then as others said package and unpackage in another location works best. I have been doing this for years between different systems as I move and work on. I never do any cloud or server stuff, always reliable usb media based moving and placing and all my work has been that way, yes you will have lots of duplicates of said hardware but this gives me a peace of mind, anytime I want to go and make major changes and want to preserve the current state, I simply copy my project folder.

    Honestly storage is not an issue these days with terabyte SSD's and usb drives in same area if not in the 100's of gigabytes
  8. Lew_Merrick

    Lew_Merrick Alibre Super User

    Hi Jason -- First of all we need to set-up terminology On my side of the universe Designs are broken into Projects and the "Top Assembly" within a Project is called the Installation. [Just to define things.] Thus, each Project gets its own Directory that defines things fairly clearly (such as "Gonkulator Project 20200720-New"). Into this Directory goes all the Project overall data (what does it do, how does it do it. etc.) and the PDF Drawing Dataset for the Project at it's "released configuration set.

    Immediately "below" that will be an Installation sub-Directory into which all the "Top Level Files" get placed. Within this Directory "sub-sub-Directories" for such things as (say) Fasteners, Purchased Components and (potentially several) "Major Assemblies" get placed as well as such things a "Parts List data." "Installation Operational Documents" and "Drawings" that relate to the Installation and the like. If Parts are created that only apply to the Installation, they get stored here (along with appropriate Documentation).

    "Below" each "Major Assembly" directory will be appropriate "Sub-Assembly" and "Parts" directories as well as "Sub-Assembly Drawwings" and the like. I belive that you can see where this is heading. When complete the entire "Project Directory" can be "zipped" (though I use "7-zip") and stored as a complete Archive. So long as the "base path" is correct (and I use "J:\Lews_Data\Designs\Projects\" as my "base path") all is well when it is "restored." Mainly it boils down to building habits and following them.
  9. Mika

    Mika Senior Member

    This file management thing have been quite a big headache for me while using Alibre. If even a little changes are made in folder structure where those files are stored, Alibre will lost the connection to those parts when opening a assembly. Folder structure of project need to be really carefully planned already before the project, otherwise big file management problems are coming if you want to make some changes.
    jfleming likes this.
  10. JST

    JST Alibre Super User


    Is not an everyday headache, but when it comes up, it is a real pain.

    Work directories / Project directories are the answer. Default everything to save to and be loaded from the defined current work directory, EVEN IF IT CAME FROM A DIFFERENT DIRECTORY (such as a "parts library").

    "ALLOW" saves to anywhere, but return to the default afterward, automatically.
    albie0803 and jfleming like this.
  11. GIOV

    GIOV Alibre Super User

    Do a simple spreadsheet with the Assemble & its Parts files linked. If something happen only need to do a replace component with or without its constrains based from the spreadsheet directory.
  12. JST

    JST Alibre Super User

    And update it continuously with all changes, and keep it with the model and...and...and... I'd rather be assigned to keep up the PERT chart.......:eek:
    Mika likes this.
  13. GIOV

    GIOV Alibre Super User

    Ah, Yes, for one side you don't have file confusion and for the Pert you add a column by data modified of each row part & assemble..
    Mika likes this.
  14. Mika

    Mika Senior Member

  15. Lew_Merrick

    Lew_Merrick Alibre Super User

    Hi Mika -- That is the advantage of appropriate Project Archiving. Let us say that we have (if you will) "Project Harry" that is stored "beneath" the Folder "C:\Harry." I can name my Installation Model as (say) Installation 20200726New Harry. Everything making up and defining "Rev New" of Project Harry is defined in "folders" that lie "below" "C:\Harry\." When I "7-ZIP" my "C:\Harry\," location it is stored in a manner that properly "links it" for Alibre Design. Un-Zipping it into a "C:\Harry\" location will "restore" all the "links" with respect to Alibre Design. It is that simple. -- Lew
  16. Mika

    Mika Senior Member

    Keeping hundreds of files(maybe thousands) in a one folder is surely quite a easy. Project might have many different devices to design and those ones is nice to have their own folders. Also separated device folders might have different folders for modeled parts and assemblies, to make it more simple to view it.

    Then we have a folder structure which one you cannot change anymore, once it is created. Opening an assembly need to relocate all the parts and that is quite a big job to do if assembly is including [lets say] hundreds of parts.
    Last edited: Jul 27, 2020
  17. simonb65

    simonb65 Alibre Super User

    Most problems with linked files occur when the links are 'absolute', i.e the full path of the link is used. Most software development environments use 'relative' links, so the name of where the top level project file is not important, as long as the folder relationship of the child dependencies is maintained.

    My approach is to use a free version control software (cvs or svn), at each new version of Alibre, I tag all the files for the current version, then if a newer version of Alibre causes issues, I just roll back my design files to the last known good version and go from there. My common and shared parts have their own diectory and folder structure, so the project directory usually only has project specific parts, assemblies and drawings. Utilising the 'shared' parts library, who's location and structure never changes. Would like to see Alibre implement a proper 'read only' library and stop asking to save those when I change my assemblies ... but ever since I stared writing software, file versioning, backup, archiving and sharing common files was always an issue until a disciplined system to manage that issue was put in place. Something your average user never really thinks about until it goes wrong!
  18. simonb65

    simonb65 Alibre Super User

    Not good practice! If you have a disk error which corrupts the file system, you only have to loose one link to that directory and ALL your files are gone! There is also a limit to the number of files in each directory (defined to the FAT filing system) and disk access times are increased having a 'flat file' architecture. Also not very good for the human to find things either.
  19. simonb65

    simonb65 Alibre Super User

    That's why software developers/businesses spend time and resources planning these things up front. Planning ahead is the key to success.
  20. Lew_Merrick

    Lew_Merrick Alibre Super User

    Hi Mika -- If you go through my posts, you will find several messages to the "how's" of organizing such a system. In my approach, all Fasteners and Purchased Components get their "own Folder" at the "Project Level" of organization. Should such a component require "modification" it gets its own Part Number as it is now a "Make" item rather than a "Buy" item. Should you need to makes changes to (say) "Project George 20200715 Rev B," you do so within that context -- you just rename the Project to (say) "Project George 20200727 Rev C" and all "associated Parts and Assemblies to their own Revision Level.

    Yes, this is a PITA and it would be a whole lot easier could we Rename component files from within Alibre (something for which I have been agitating since 2009). Archiving Projects is something you learn whilst working under Defense Contracts Administration & Security Services -- Something I can assure you on no uncertain terms. -- Lew

Share This Page