Presently it appears that the oDrive PC/desktop app maintains cloud-mapping info for unsynced placeholder folders/files (I’ll call these “objects”) in a database/list (json?) located somewhere within it’s program space on a person’s PC desktop environment.
(I reach this simple conclusion because of two important observations down here in userland: 1.) the placeholder objects are zero sized, thus they contain zero information; and 2.) It’s not possible to move these placeholder objects - doing so breaks their ability to re-sync back to their referenced cloud-resident objects; Thus, the mapping for each placeholder object is created and resident in a static DB/List used by the app located somewhere in the PC/Desktop environment.)
Placing the placeholder objects cloud mapping info INSIDE of the placeholder file (thus making it larger than zero bytes in size) (either in-addition-to or instead-of the present DB/list approach) could enable a load of kool new capabilities presently absent in oDrive:
1.) placeholder objects could be moved and re-synced to ANY new/different location anywhere within a user’s PC desktop environment (and/or also onto any attached/mapped ext HD);
2.) original file-size info (and other useful original-file attributes) could be embedded within the placeholder object (in addition to the cloud-mapping/remote-directory-tree info) enabling reporting of this useful search meta-info back to userland;
3.) embedding oDrive UserID info could enable a user to move or copy any placeholder object of his on any platform over to any of his other PC / server / tablet / smartphone devices also running oDrive. (When the oDrive app on any of these devices receives a request to resync a placeholder file, this embedded UserID info can help to map back to the initially performed cloud-device authentication store.)
If such capabilities were ever to make it into oDrive, the maximum placeholder object size should be kept to less than the minimum sector size supported by the userland desktop OS… in Win environments, this value is either 1k or maybe even 512 bytes. The benefit to keeping the placeholder object size less than this value is that this will encourage creation and use of HD partitions optimized for placeholder particular use.
Today my media files are stored on local HD partitions all set to the maximum sector size of 64k. For these (usually) large sized files, this large sector size makes the best (most storage efficient) sense. As my use of oDrive placeholders on these HDs grow however, the 64k sector size (to hold the un-synced placeholder objects of zero size) will grow ridiculously onerous… I’ll loose a large amount of storage space to all these “zero sized” 64KB placeholder objects!
Since these small placeholder folder/files are so very special and important, they warrant their own specially created and dedicated HD partition (perhaps my local/internal HD space I’ll designate as my “D” drive). So, rather than waste 64KB on each (either empty or very small sized) placeholder object, I’ll instead only use either 512 or 1024 bytes for each… eventually as the count of these placeholder objects grows, I’d be saving a very large amount of local HD space by only storing these special oDrive placeholder objects in this special HD partition space.
If anyone’s concerned about forgetting where in one’s local expansive storage space these placeholder objects were originally created to represent an un-synced relation to an external cloud-stored object - they can either rely on interrogating a placeholder objects embedded meta data on this, or they can also replicate their expansive local directory tree structure into the special “Placeholder Object Drive D” space… Once they want to re-sync any placeholder object, users will either have to manually move the placeholder object back to it’s original (or new/different) directory location (which will be using much-larger/more-efficient sector sizes than the “D” partition), or perhaps the oDrive process can somehow help out with these details… making this process a bit more of an “automatic” type experience for the user…
I think this enhancement in the oDrive system design could bring an explosion of new cloud-management capabilities down to users’ desktops… and other (more often offline) devices like phones and tablets also.