Re: two approaches to file tree recursion with *at() syscalls
- From: phil-news-nospam@xxxxxxxx
- Date: 20 Jul 2008 15:21:57 GMT
On Sun, 20 Jul 2008 06:06:26 -0700 John Reiser <jreiser@xxxxxxxxxxxx> wrote:
|> | Is the file graph contained in a single block device (no mounts, no
|> | off-device symlinks)?
|>
|> No guarantees. [For this or any other "nasty" condition.]
|
| In such cases then neither of the two proposed recursion solutions (keep open
| directories on path from root; use just one open directory, plus "..")
| is safe to walk the graph. Because the graph may span devices,
| may contain arbitrary loops, may be mal-formed, may be on a filesystem
| with a different notion of "directory", and may be changing as you walk,
| then you must keep a history of the device number, inode number, name,
| and creation+modification times of each entry, to help you navigate and
| detect and avoid getting lost in loops. Even then, a clever concurrent
| adversary can force an infinite traversal within a finite graph,
| with probability greater than zero.
I know that neither method is perfect. If one of them was, I'd use that.
What I want to figure out is which method would be more appropriate to use
in general for most cases, or in a specific case.
I'm writing a program to do file copying of a tree to another. Mostly it is
intended as a fast and ordered copy program. But I am also making it handle
target replacement, which can involve deleting a directory subtree at the
target, as well. So the code could have tree walk both for copying source
to target, as well as deletion of (parts of) the target.
Maybe the specific case(s) will be better served by one of these methods.
The uses I would apply this program to would not have the tree changing
during the copying (or of the deletion of a target). Someone else might
try to do that. It is possible that the source tree could span filesystem
mounts. I will be tracking device and inode already as part of replicating
the source's hardlink relationships into the target. It seems that mounts
simulate fake ".." entries that always go to the parent of the mount point,
or to "/" itself for the "/" mount point.
I'm contemplating some kind of hybrid method that uses an open descriptor of
each directory level, then switch to the other method of closing directories
and reopen them coming back up when descriptors run out. The catch with that
is I need a few reserve descriptors, so I need to transition between methods
before actually running out. I'll need at least 3 reserve descriptors. I'd
have to trust sysconf(_SC_OPEN_MAX) or something to count them on my own.
--
|WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
| by the abuse department, bellsouth.net is blocked. If you post to |
| Usenet from these places, find another Usenet provider ASAP. |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |
.
- References:
- two approaches to file tree recursion with *at() syscalls
- From: phil-news-nospam
- Re: two approaches to file tree recursion with *at() syscalls
- From: John Reiser
- Re: two approaches to file tree recursion with *at() syscalls
- From: phil-news-nospam
- Re: two approaches to file tree recursion with *at() syscalls
- From: John Reiser
- two approaches to file tree recursion with *at() syscalls
- Prev by Date: Re: two approaches to file tree recursion with *at() syscalls
- Next by Date: Re: Automatically shut down computer after inactive time
- Previous by thread: Re: two approaches to file tree recursion with *at() syscalls
- Next by thread: Re: two approaches to file tree recursion with *at() syscalls
- Index(es):
Relevant Pages
|