Brian Dessent wrote: > Gmane User wrote: > >> I'm defragging the whole disk, so I need the defragger to be able >> to access all files from whatever account it runs under. > > I've never had any problem doing that without having to specifically > loosen any ACLs.
Let's make sure we're comparing the same situation. I've used bash to explicitly change permissions to go-rwx for most of my files. This is on a nonadmin account. This is what chokes the defragger. Do you have the same circumstance? >> About defragging as a service, >> http://support.microsoft.com/kb/120929 says that the System account >> has no more permissions than an admin account. > > I use O&O Defrag, it runs as a service as NT AUTHORITY\SYSTEM, and > it defrags all my Cygwin files just fine without needing to set any > special permissions. It has been the same way with every other > defrag program I've used too. > >> About defragging on boot-up, JkDefrag does this too, but still >> needs an account to run under. Is it possible for a defrag (or a >> process) to run not under any account? That is, does Ultra >> Defragmenter actually do this? Ultra Defragmenter would have been >> my first choice, except that I ran into this caveat: > > At the point where UltraDefrag runs only the kernel and drivers have > loaded, the Win32 subsystem and the SAM do not even exist yet -- > this is the whole point of doing it that early in the process, so > that things like the registry hives are not yet open and locked. So > I think this runs in the absence of any user context. And even when > doing a normal defrag, UltraDefrag does the actual processing in > kernel mode as a driver and at that level there are no access > restrictions whatsoever. Hmm. That raises questions in my feeble mind. I wonder why JkDefrag requires the specification of a user account for the boot-up defrag. Anyway, I will try Ultra Defragementer. Thank you for the reassurance and explanation below. I have my fingers crossed. Actually, I'll try a boot-time defrag with JkDefrag first. But Ultra is next, if the same problems arise. >> http://groups.google.ca/group/alt.comp.freeware/browse_frm/thread/377f0ea5602cc584/855cc4e01f835029. >> I described in my original post the barriers to ghosting in my >> obsolete system, so I'm reticent to experiment with developmental >> defraggers until they built up a bit of a track record. This >> decision has more to do with safety than how well the algorithm may >> be coded up. > > Keep in mind that all of these things are using the same code for > the heavy lifting of actual defragmentation. That is implemented in > the NTFS.SYS filesystem kernel driver; none of the tools actually > touch the raw disk, they just send an IOCTL to the filesystem > telling it to move a file extent from A to B. The only thing that > differs is the high level algorithm that decides what goes where, > but none of them do the actual moving. The risk of data loss > therefore is more or less constant and does not depend on which tool > is being used, as I see it. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/