shorten long paths in deeply nested directory structure
 

I would like to shorten some long paths in a deeply nested directory structure. The directory structure itself starts several levels down from root.

So let's say i have a directory structure with path depths varying from 1 to 15 (counting the directory structure as level 1).

I want to find all paths that go to depth of at least 5.

& then snip each path at level 5 and move it (along with its subdirectories) to level 2.

The net result of all this will have been to reduce maxdepth by 3 (i.e., from level 15 down to 12).

I don't want to flatten the directory structure -- that's more flattening than I need. I just need to flatten it a little so that it doesn't create errors in certain operating systems doing certain procedures.

I'd also like to include echoing each step to the standard output to make sure I'm not doing this on the entire file system.

Is there a way to do this?
Thanks.
EVL

Is a Perl program acceptable to you?

Or -- lets talk about the "errors in certain operating systems doing certain procedures" -- perhaps flattening the directory structure is not the best solution to the problem.

Perl Program to shorten directory paths
 

Yes, absolutely .. As long as I know how to execute it .. not sure I've ever run a Perl program.

flatten directory structure vs errors in OS
 

Great idea .. how do I translate that into a solution?

BTW, my printout of the directory tree suggests nesting up to 20 levels deep.

I'd probly wanna flatten it to maybe 10 levels -- even if it's an OS problem I can circumvent.

Which procedures of which OS might be problematic with deeply nested directories?

Thanks much for your help.

Eric

So if you have a directory /path/to/some/of/my/really/cool/computer/files you want to move of/my/really/cool/computer/files to /path/to/cool/computer/files? What if there's a directory with that name already there? Merge them, or rename it by adding 1, 2, 3 etc.?

I'm basically suggesting that the solution to your problems might not be to flatten the directory structure, but lie elsewhere. I could be wrong, of course, or you may not care to investigate another solution.

If you do, please explain what problems you are having that you're attributing to the depth of your directory structure. That is: Which procedures are causing errors because of the long path names? What are you trying to do that not working because of long path names?

If not, please excuse me...

If there's a directory with that name already there, rename with incrementing number.
 

Good point .. Probly rename with incrementing number.

Thanks.

Eric

what problems you are having that you're attributing to the depth of your directory structure
 

[QUOTE=scasey;5729562]I'm basically suggesting that the solution to your problems might not be to flatten the directory structure, but lie elsewhere. I could be wrong, of course, or you may not care to investigate another solution.

If you do, please explain what problems you are having that you're attributing to the depth of your directory structure. That is: Which procedures are causing errors because of the long path names? What are you trying to do that not working because of long path names?


I SEE YOUR POINT .. One thing is copying for the sake of backup. Searching for files by content.

But even more, just I never know what I'm going to try to do with the files in future -- or on which system (I use mac/win/linux/android). So I just kinda wanna know that whatever I try to do in future will go without a hitch -- at least not cuz excessive nesting depth.

BTW -- the whole thing right now is on exfat file system hooked up to mac (easy to reconnect to linux, though)

Thank you.

Eric

Ahh yes. I have experienced those kinds of issues, but the problem has been the number of files the command tried to return, not the depth of the file structure. Flattening the structure won't reduce the number of files. Can you show us what happens?

problem is number of files -- not depth of nesting
 

I'm going to try to remember or duplicate what happened & post it then .... For now, I seem to recall copying all files from a failing drive, but all files didn't copy, & I believe nesting may have been the issue. I'd like to toss the old drive, but not till all files have copied.

For now, I just have a general memory of something going wrong when data was deeply nested -- but not when i reduced the nesting.
I don't recall how many files there were in either case.

I'd be curious if there's a max number of files one can use in one operation on mac/linux/win etc .... If there is such limit, it would be a good thing to know.

I've heard of a limit on path length, i.e., number of characters. But the previous 256 (+ or -) has been transcended on windows & doesn't exist on mac or linux, I believe.

Thanks for your continued feedback.

Why not use a symbolic link?

e.g. create a directory at level 5 called 'some-links' which points to a some deeply nested "parent directory"
It will ease your navigation through loads of files.

For example:-
then,

Let's talk about backups. ;)

Certainly. I suspect a got "too many arguments" sometime in the past, but (as you know), that's probably not the best way to make a backup.

I use rsnapshot, which uses rsync, to make off-site backups of my production server and same-site backups of my backup server.

One of the problems for backups is that it is easier to take a backup than to do a proper restore!

rsync has quite a complex set of possible parameters...

I use backup2l which produces daily tar.gz files, so in a dire emergency, I could do a "manual" restore; even if I'd lost all details of the backup parameters.