Re: need a good idea for catch files deleted
- From: elgiei <liuggio@xxxxxxxxx>
- Date: 13 May 2007 03:37:36 -0700
elgiei <liug...@xxxxxxxxx> wrote:
my server already works with
pthread, socket, signal for timer
None of those are part of standard C; those are all operating
system extensions.
ok i can use operative extensions infact in my code i used
#ifdef WIN32
and the else for linux..
so if my hard disk is composed only by :
/home/elgiei
/home/elgiei/file2.jpg
/home/elgiei/Desktop
/home/elgiei/Desktop/file1.jpg
my ntree is :
------/home/elgiei------------------------
--------- /--------\---------------------------
file2.jpg--------/home/elgiei/Desktop
-----------------------|-----------------------
------------------file1.jpg-------------------
(remove "-" with space)
So if there are duplicated prefixes, you store the prefix once per file?
That's less space efficient than it could be, but does make it easier
to insert or delete new nodes.
i don't know if i really understand the prefixes
in each file i already stores path/file
i don't write in that picture for space's problem.
/home/elgiei/file2.jpg--------/home/elgiei/Desktop
---------------------------------------------|-------------------
-----------------------------/home/elgiei/file1.jpg--------
and really each node has a md5 (message digest) value
it's the sum of the md5 of his son
so if nothing is changed i don't need to compare both tree, so i
compare only the modified branch
(if someone don't understand this part can asks but it it's not useful
for the solution of the problem)
That's less space efficient (really less space efficient) but it's
faster (really faster)
after 60secs i rebuild a new ntree and i do a diff (ntreeNEW,ntreeOLD)
and i check the differences..
but it's not a smart solution for large data.
It seems to me that you don't need to build a new ntree and do a
comparison. Provided you use a consistant ordering (e.g., depth-first,
sorted order), you should be able to start at the beginning and trace
the existing ntree through for each file: if you are processing a
file that is not part of the current n-tree then it is a new file,
and if the next file does not correspond to the next node threaded
along the leaves, then any nodes that were skipped in the process
were removed (or renamed.) It shouldn't be difficult for you to
add threading between the leaves.
yes it's a good solution,
but i build my new ntree becouse comparison is faster,
and after 60-sec it becomes the old ntree i have to build a new ntree
for comparison.
is there a signal Handler for catch file removed ?
As I indicated earlier, standard C doesn't know anything about
directories -- and all it knows about files is that if you
pass a complete null-terminated string to fopen() then some
file somewhere will be opened (or the open will fail.) Standard C
doesn't know anything about what those filename strings -mean-.
Thus, of course there is no signal or any other method in standard C
of detecting that a file has been removed: the existance of such
a function would require knowing something about filesystems, which
standard C does not.
There might be a mechanism in your operating system to notice such
things, but any such facility would be OS-specific, and you would
need to inquire about it in a newsgroup that deals with your
(unnamed) operating system. (I wasn't able to deduce which OS you
are writing this for; you mentioned inotify() which appears to be
Linux-specific, and you mentioned ext3 filesystems, which appear
to be Linux-specific, but you also mentioned NTFS filesystems,
which are proprietary to Microsoft Windows.
Yes my server must play on linux and win32
D'oh might be..
Anyone knows?
It's a great idea i'll search for win32 newsgroup and linux too
(suggested groups?)
anyone has a better idea????
What is the object of the assignment?
To explore efficient use
of tree structures, or to explore how one would implement OS
facilities if those facilities were not already provided?
is do a server for win and linux..
but the really problem is check in the better way,files deleted and
modified in filesystem ext3 Ntfs
:(
.
- Follow-Ups:
- Re: need a good idea for catch files deleted
- From: elgiei
- Re: need a good idea for catch files deleted
- References:
- need a good idea for catch files deleted
- From: elgiei
- Re: need a good idea for catch files deleted
- From: Walter Roberson
- Re: need a good idea for catch files deleted
- From: elgiei
- Re: need a good idea for catch files deleted
- From: Walter Roberson
- need a good idea for catch files deleted
- Prev by Date: Re: about mount func.
- Next by Date: Re: access of memory beyond allocation, not causing segmentation fault...
- Previous by thread: Re: need a good idea for catch files deleted
- Next by thread: Re: need a good idea for catch files deleted
- Index(es):
Relevant Pages
|
Loading