And Rename It To A Unique File Name So That: Fill & Download for Free

In my view there are three key principles to maintaining a personal library of photos. Using just these key principles, it's no problem to maintain a personal library consisting of 100,000+ images. Most modern photo software, such as Adobe Lightroom, provide the tools needed to implement such a system.Unique file name for each image.The first principle is to provide each photo with a unique name. This is simple to do. For example, you can set up the import dialog in Adobe Lightroom to rename on import using a YYYYMMDDHHMMSS format, where the date/time data is extracted from the image EXIF data. This convention can be applied to any image, whether from a camera, cell phone, scanner, or screenshot. In fact, if you sync the date/time on each device, this allows you to shoot an event with multiple cameras and easily integrate the images after the fact.There are many advantages to using unique file names.It's easy to track down an imageYou can move images around your folders without having to worry about accidently overwriting an image.Avoids unnecessary duplication of images.Use metadata to record information about images.Using filenames to record information about images never works. For one thing, you just can't store enough information, or reliably sort and find images (you're looking for that picture of nephew joe with the fish he caught at our cabin a few years ago. Now how did I name that?).That's was metadata is for. Standard tools (like Adobe Lightroom) provide excellent tools for recording and editing keywords, location data, adding stars to track those you would use for presentation or portfolios, and so on. If you try to track this in file or folder names, you'll end up having to change filenames if you decide to change a keyword, or store duplicates if you want to track with folders. It's just a mess.By storing the metadata in the image files, you can always reconstruct your image catalog should it ever become corrupted. I've done this on at least two occasions, both times rebuilding catalogs for 30,000+ images. This works.Learn to use metadata.Use non-destructive editorsFinally, learn to use modern non-destructive editors. These store the edit information in the metadata, so that (most of the time) it isn't necessary to maintain derivative versions of a particular image. If you need multiple versions of an image, you can do this with 'virtual copies'.

I don't have any idea how file system is implemented in Windows. But have an idea about Linux.In Linux every file is recognised by structure called inode. Each structure has a unique number and every file get only one inode number. This structure has lots of information. That includes file-size, file-permissions, time stamps, pointer to disk blocks etc. Please note that inode doesn't know the file name.So, where does it gets the file name? In Linux most of the things are files, including directories. Each directory has a filename entry and the inode number for lookup. So, a file (an inode number) can have as many pointers you like. And when you open a file, a File descriptor is created using the unique inode number associated with file name.The process which has opened the file is by file-descriptor, which is using the inode. If you rename the file, you actually changing the content of a special file (i.e., directory) which has the file listed in it. Similarly moving the file is straight forward, you are actually removing the file entry from one directory and adding it somewhere else. And application read-write continues as normal.Also, any number of process/applications can point to a file. In inode there is a field called link. It maintains count of links to the file. So, if file is present in a directory its link count is one. If it has a Hard link, then link count will be two. If it is opened by a process link count will be incremented by 1. And so on.One common mistake, I see new developers on Linux do this common mistake. They delete a log file of running process and expect disk space to be freed. However, things don't work this way. The inode still has a counter which is not zero, because process is still using it.Hope, I was able to answer your question. Following link might be helpful: inodeLet me know if you have further questions.

A renaming apps will allow you to rename the files but what if the reason the file names are so long is to preserve their uniqueness? In that case shortening them could be an issue. If the file names aren't meant to be read by humans you might be able to compress the string that comprises the name itself or apply a hashing algorithm to retain the files uniqueness. Compressing the names would allow you to decompress them later should the original file name be required.If the combination or the file name AND path is what is causing the name to be too long, changing or shortening the directory structure's name could resolve the issue.Remember:More information = Better advice.